<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head>
<!-- Copyright (C) 2017 Arm Ltd. All rights reserved. -->
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Release notes for Arm Compiler 5.06 update 6</title>

<style type="text/css">
<!--
body { font-family: times new roman, serif; margin: 20px; }
h1 { font-size: xx-large; font-weight: bold; color: #0091BD; text-align: center; }
h2 { color: #0091BD; font-size: 24px; }
h3 { color: #0091BD; font-size: 20px; }
h4 { color: #0091BD; font-size: 16px; }
h5 { color: #0091BD; font-size: 14px; font-style: italic; }
dt { font-weight: bold; }
p { color: black; }
span { color: black }
.builddata { color: #0091BD; text-align: center; }
.bookref { font-style: italic; }
.guiref { font-weight: bold; }
table, th, td { border: 1px solid #0091BD; border-collapse:collapse; padding-left:10px; padding-right:10px; font-size:0.9em; }
th { background-color:#0091BD; color: white; text-align: left; }

.toc {
    list-style-type: none;
}
.tab { margin-left: 40px; }
-->
</style>

</head>
<body>

<img alt="Arm Logo" src="data:image/png;base64,
iVBORw0KGgoAAAANSUhEUgAAAIMAAAAqCAYAAACQjuhAAAAACXBIWXMAABcRAAAXEQHKJvM/AAAE
BElEQVR42u2c23GjMBSG/zD7vpRACbiCkKGAdSoIVCC7AuwKbFVgbwX2FsCEVBC2gng7IBXsPkis
GcLlSGAMtv4Zv3iMLkefjs4RkgEjIyOjsh60n+SxA8AD8AjAlZ+yUgAJgF9gflJRhtdSSwbmp8S2
OI2/KdbPYxtAAOCH7INau3XqFM/MC3U6NXVyMP9E7PNc2t8DYFeUl8o+HC8DgxhAJhuiohOANZi/
L5T1t+WZBMx/IrRpBSBqGZiHwoDsKoxX3wYg/DJAanV6ADY1E6ZKewBLMD+rgSCSMKvYftkGhaXk
CXh8APCqAQLkTNiBx69yZg4vHm8AHBRAgBzArEOdC2kzV+GpAMA7eOyWyhLfq4GQ2/4AHu+6wyBm
07smBGV5AIYHQhhiofHksXKG0uHbaLbYkXZyCyDsFEH+ClkDEBahQ4HGbKLMtteB/UKg+dy6Q52L
jm22pTfNQejHDgJSRRj6bUQVEGPXkRTMXVbuBcZgURW8Ww0guBcEYSriN9y3iAaDWM8PGhVkMvrO
P6cJGyutTSu7lnu2Tx/KNO3tyczkv741rHWOQsF7mR+nNalQINNRe0SDLfYRxOAUg9sX2fe+vcJR
pnen0qSLNGOLTJa3r0j9d8TxmwPY1sNwzmOp+WvYOINE51fg8VY2cn5lCDIAzzVtTmRbgy9G7qaw
sjyRpSzB408Fm+d2f6qMZ5ifgMczAB+EyfdYhMHqEHWnAGZkV8r8DMx/ll7kmiA8tba5XxCOreUx
f6Xo4p8bA9scMsUgvgqGF6JRQ638m/mhdJnX0Jq0vd2vlmRoqEsyrQ+U8px6GEQG4Qxg1BBddvV0
vQLztyNOTd+Iv/tJ9sSKQapVEVC0r1ddjSoaygcfmOH1W3EJo9gu6bXMwpa3VRFQ9EMmLQMZUm9X
gCFRmCCU36YXgNGug8EZbIYJ9znk+j3lPQ8176EpdRj6DcCSWzHkLci68uB9DtbT4bMIHbc+KRiM
1ANlA8MdreN3u0z0LccMwXRhcI3J7geGtoDHLr/27KhHMwTjhYGyhvfz1lG8vvXMEIwXBsouHeup
7rkx/7hhoOwjOPJsZFevEBnzjxkGsTFDWSo2HY+6RyaTmEY2QXmbaEP37oPwKgtj+mnAsAdtH9+V
QDgKIKxgTlxPCAa1swYuxDWwVSMUPA7A4w8TJ4xbdaejtzifEqYsGRGACDzOb/7+AfBdwmLSx0nD
wPwMPA6hfgWu7mq+0URjhhyIBOKsotHdwyCA2KPbxVOjm4FBALG6gIfIjNeZIgxnDzFDPyd3ThAX
WfbG/FOEQQCRgvkzOaNPmt5gDXELKzWmH5+6/MFX8c+l3AYAEogLrsepHQMzMOjD4ZT2JVIz+EZG
E9U/yX9anPUqLjMAAAAASUVORK5CYII="/>




<h1>Release notes for Arm Compiler 5.06 update 6 (build 750)</h1>



















<h2>Table of Contents</h2>

<ol class="toc">
  <li>1. <a href="#introduction">Introduction</a></li>
  <li>2. <a href="#install">Installation Instructions</a>
    <ol class="toc">
      <li>2.1. <a href="#install_ds5">Integration into DS-5 5.20 or later</a></li>
      <li>2.2. <a href="#install_mdk">Integration into Keil MDK 5.12 or later</a></li>
      <li>2.3. <a href="#install_standalone">Use as a standalone product</a></li>
      <li>2.4. <a href="#install_linux">Installation on Linux</a></li>
      <li>2.5. <a href="#install_windows">Installation on Windows</a></li>
    </ol>
  </li>
  <li>3. <a href="#uninstall">Uninstall</a></li>
  <li>4. <a href="#documentation">Documentation</a></li>
  <li>5. <a href="#feedback">Feedback and Support</a></li>
  <li>6. <a href="#history">Release History and Changes</a></li>
</ol>


<a name="introduction"></a>
<h2>1. Introduction</h2>






<p>
This is the initial set of release notes provided at the time of the release. For the latest copy of the release notes, see <a href="https://developer.arm.com/products/software-development-tools/compilers/arm-compiler/downloads/version-5/5-06u6">the latest version</a> on <a href="https://developer.arm.com">https://developer.arm.com</a>.
</p>


<p>
Arm Compiler 5.06 is the final release series of Arm Compiler 5 and is
succeeded by Arm Compiler 6.
</p>


<p>
For projects with safety certification requirements, specific releases are
available beginning with Arm Compiler 5.06 update 3 for Certification.
</p>


<p>
This release, Arm Compiler 5.06 update 6, is the last planned update release in the normal maintenance period. 
After this, further support and maintenance will be available through Arm Compiler Long Term Maintenance releases with maintenance continuing until at least summer 2020.
Arm Compiler 5.06 for Certification and Arm Compiler 5.06 Long Term Maintenance releases will each be supported by an Arm Compiler Qualification Kit.
</p>

<p>
More information is available from the following links:
</p>
<ul>
<li><a href=" https://developer.arm.com/products/software-development-tools/compilers/arm-compiler">https://developer.arm.com/products/software-development-tools/compilers/arm-compiler</a></li>
<li><a href=" https://developer.arm.com/products/software-development-tools/compilers/safety">https://developer.arm.com/products/software-development-tools/compilers/safety</a></li>
</ul>

<p>

Arm Compiler 5.06 update 6 (build 750) is an update release to Arm Compiler 5.06 and is intended for use:

</p>
<ul>
<li>With DS-5 Professional Edition or DS-5 Ultimate Edition.</li>

<li>With Keil MDK-Standard, Keil MDK-Professional, or Keil MDK-Cortex-M.</li>

<li>As a standalone toolchain installation.</li>
</ul>

<p>
A suitable license from one of these products must be available.

Contact your sales representative or visit <a href="https://developer.arm.com/products/buy-arm-products">https://developer.arm.com/products/buy-arm-products</a> to enquire about a license. 
</p>

<p>
If you are using a floating license, your license server must be running <tt>armlmd</tt> and <tt>lmgrd</tt> version 11.14.1.0 or later.
Arm recommends that you always use the latest version of the license server software that is available from
<a href="https://developer.arm.com/products/software-development-tools/license-management/downloads">https://developer.arm.com/products/software-development-tools/license-management/downloads</a>.
</p>

<a name="install"></a>
<h2>2. Installation Instructions</h2>

<p>
If you received Arm Compiler 5.06 update 6 as part of a toolkit (DS-5 or Keil
MDK), the toolkit installer takes care of the installation process.
Please refer to the installation instructions for the toolkit in such cases.
</p>

<p>
For all other cases, you must select an appropriate installation location
depending on how you intend to use Arm Compiler 5.06 update 6:
</p>
<ul>
  <li>Integrated into DS-5 5.20 or later.</li>
  <li>Integrated into Keil MDK 5.12 or later.</li>
  <li>As a standalone product.</li>
</ul>

<a name="install_ds5"></a>
<h3>2.1. Integration into DS-5 5.20 or later</h3>
<p>
Arm Compiler 5.06 update 6 can be installed in any location, including the
default location, providing this is outside of a DS-5 product installation.
</p>

<p>
After it is installed, you can integrate the toolchain with DS-5 5.20 or later by following the instructions in the tutorial available at
<a href="https://developer.arm.com/products/software-development-tools/ds-5-development-studio/resources/tutorials/adding-new-compiler-toolchains-to-ds-5">https://developer.arm.com/products/software-development-tools/ds-5-development-studio/resources/tutorials/adding-new-compiler-toolchains-to-ds-5</a>.</p>

<p>
Arm recommends using Arm Compiler 5.06 update 6 from the DS-5 Eclipse IDE or
DS-5 Command Prompt. When using the toolchain outside these environments,
you might need to configure the following environment variables:
</p>
<ul>
  <li>Set <tt>ARM_PRODUCT_PATH</tt> to the path to the <tt>sw/mappings</tt>
      directory within your DS-5 installation.</li>
  <li>Set <tt>ARM_TOOL_VARIANT=ult</tt> if you are using the toolchain with DS-5
      Ultimate Edition.</li>
</ul>

<a name="install_mdk"></a>
<h3>2.2. Integration into Keil MDK 5.12 or later</h3>
<p>
Arm Compiler 5.06 update 6 must be installed underneath the <tt>ARM</tt>
subdirectory of the Keil MDK installation. For example, if your Keil MDK
installation is in <tt>C:\Keil_v5</tt> the recommended installation path is
<tt>C:\Keil_v5\ARM\ARM_Compiler_5.06u6</tt>.
</p>
<p>
After it is installed, you can integrate the toolchain into a Keil MDK project
by following the instructions in the Application Note available at
<a href="http://www.keil.com/support/man/docs/uv4/uv4_armcompilers.htm">http://www.keil.com/support/man/docs/uv4/uv4_armcompilers.htm</a>.</p>

<a name="install_standalone"></a>
<h3>2.3. Use as a standalone product</h3>
<p>
Arm Compiler 5.06 update 6 can be installed in any location, including the
default location, providing this is outside of a DS-5 product installation
and outside of a Keil MDK product installation.
</p>

<p>
Ensure that the <tt>ARMLMD_LICENSE_FILE</tt> environment variable is pointing to your license file or license server. 
Please note this path must not contain double quotes on Windows. 
A path that contains spaces will still work without the quotes.
</p>


<a name="install_linux"></a>
<h3>2.4. Installation on Linux</h3>

<p>Arm Compiler 5.06 update 6 has been tested on the following supported platforms:</p>
<ul>
<li>Red Hat Enterprise Linux 6 Workstation.</li>
<li>Red Hat Enterprise Linux 7 Workstation.</li>
<li>Ubuntu Desktop Edition 14.04 LTS, 64-bit only.</li>
<li>Ubuntu Desktop Edition 16.04 LTS, 64-bit only.</li>
</ul>

<p>Run <tt>Installer/setup.sh</tt> and follow the on-screen instructions.</p>

<p>
Only a 32-bit installer is provided. The tools package includes a separate set of binaries that include a 64-bit version of <tt>armlink</tt> for use on 64-bit host platforms. See the documentation for details.
</p>

<p>
Some of the installed tools have dependencies on 32-bit system libraries.
You must ensure that 32-bit compatibility libraries are installed when using Arm
Compiler 5.06 update 6 on 64-bit Linux host platforms. Arm Compiler
5.06 update 6 tools might fail to run or report errors about missing libraries
if 32-bit compatibility libraries are not installed. To install the required
libraries, run the appropriate command for your platform with root privileges:
</p>
<dl>
<dt><span>Red Hat</span></dt><dd><span><tt>yum install glibc.i686</tt></span></dd>
<dt><span>Ubuntu</span></dt><dd><span><tt>apt-get install lib32stdc++6</tt></span></dd>
</dl>

<p>
On Ubuntu 16.04 LTS systems some of the 32-bit tools can suffer from interal faults unless a particular 32-bit libc is used. To install the required library, run the following command with root privileges:
</p>
<dl>
<dd><span><tt>apt-get install libc6:i386</tt></span></dd>
</dl>

<a name="install_windows"></a>
<h3>2.5. Installation on Windows</h3>

<p>Arm Compiler 5.06 update 6 has been tested on the following supported platforms:</p>
<ul>
<li>Windows Server 2012, 64-bit only.</li>
<li>Windows 7 Enterprise SP1.</li>
<li>Windows 7 Professional SP1.</li>
<li>Windows 8.1, 64-bit only.</li>
<li>Windows 10, 64-bit only.</li>
</ul>

<p>Support for integration with Cygwin and translation of Cygwin paths is validated against the Cygwin distribution available at the time of each release.</p>

<p>Run <tt>Installer\setup.exe</tt> and follow the on-screen instructions.</p>

<p>
Only a 32-bit installer is provided. The tools package includes a separate set of binaries that include a 64-bit version of <tt>armlink</tt> for use on 64-bit host platforms. See the documentation for details.
</p>

<a name="uninstall"></a>
<h2>3. Uninstall</h2>
<p>
On Linux, delete the Arm Compiler 5.06 update 6 installation directory.
</p>
<p>
On Windows, use <span class="guiref">Programs and Features</span> in
<span class="guiref">Control Panel</span>, select
<span class="guiref">ARM Compiler 5.06 update 6</span>, and click the
<span class="guiref">Uninstall</span> button.
</p>

<a name="documentation"></a>
<h2>4. Documentation</h2>

<p>
The following documentation is available for the Arm Compiler 5.06 release series:
</p>

<ul>
<li>armar User Guide.</li>
<li>armasm User Guide.</li>
<li>armcc User Guide.</li>
<li>armlink User Guide.</li>
<li>fromelf User Guide.</li>
<li>ARM C and C++ Libraries and Floating-Point Support User Guide.</li>
<li>Errors and Warnings Reference Guide.</li>
<li>Getting Stated Guide.</li>
<li>Migration and Compatibility Guide.</li>
<li>Software Development Guide.</li>
</ul>

<p>
For more information, please see 
<a href="https://developer.arm.com/products/software-development-tools/compilers/arm-compiler/docs/version-5">Arm Compiler 5 documentation</a>
on 
<a href="https://developer.arm.com/">developer.arm.com</a>.
</p>

<a name="feedback"></a>
<h2>5. Feedback and Support</h2>

<p>
Your feedback is important to us, and you are welcome to send us defect reports on any aspect of the product.
Contact your supplier or visit <a href="https://developer.arm.com/support">https://developer.arm.com/support</a> and open a case with feedback or support issues.
Where appropriate, please provide the <span style="white-space:nowrap"><tt>--vsn</tt></span> output from the tool, the complete content of any error message that the tools produce, and include any source code, other files, and command-lines necessary to reproduce the issue.
</p>


<a name="history"></a>
<h2>6. Release History and Changes</h2>
<p>The following are the releases to date of the Arm Compiler 5.06 series:</p>
<ul>
  <li>5.06 update 6 (released September 2017)</li>

  
  <li>5.06 update 5 (released February 2017)</li>
  
  <li>5.06 update 4 (released September 2016)</li>
  
  <li>5.06 update 3 (released May 2016)</li>
  
  <li>5.06 update 2 (released January 2016)</li>
  
  <li>5.06 update 1 (released September 2015)</li>
  
  <li>5.06 (released July 2015)</li>
  

</ul>
<p>Below is a summary of the changes in each release, including new features and defect fixes. Changes are listed since the previous release in each case unless otherwise specified. Each itemized change is accompanied by a unique SDCOMP-&lt;NNNNN&gt; identifier. If you need to contact Arm about a specific issue within these release notes, please quote the appropriate identifier.</p>

<h3>Changes in Arm Compiler 5.06 update 6</h3>




<h4>Defect fixes in Arm Compiler 5.06 update 6</h4>



<h5>Compiler (armcc)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-48383]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a <b><span style="white-space:nowrap"><tt>do</tt></span></b> <b><span style="white-space:nowrap"><tt>while</tt></span></b> loop with a controlling expression that contains a postfix decrement operator with an operand of <b><span style="white-space:nowrap"><tt>unsigned</tt></span></b> type. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-48226]&nbsp;&nbsp;In rare circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a <b><span style="white-space:nowrap"><tt>for</tt></span></b> or <b><span style="white-space:nowrap"><tt>while</tt></span></b> loop that conditionally negates a value depending on the result of a bitwise AND operation. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-48050]&nbsp;&nbsp;When compiling C&#43;&#43;11 code containing aggregate initialisation of a temporary object and that object has a non&#45;trivial destructor, the compiler would report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x87ecef:&lt;ver&gt;]</tt></span> or a Windows <span style="white-space:nowrap"><tt>APPCRASH</tt></span> error. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-47432]&nbsp;&nbsp;In certain circumstances, when compiling for an Armv6T2, Armv7&#45;A, Armv7&#45;R, or Armv7&#45;M target, the compiler could generate incorrect code for accesses to <b><span style="white-space:nowrap"><tt>signed</tt></span></b> <b><span style="white-space:nowrap"><tt>long</tt></span></b> <b><span style="white-space:nowrap"><tt>long</tt></span></b> bitfield members of a <b><span style="white-space:nowrap"><tt>struct</tt></span></b>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-47401]&nbsp;&nbsp;In rare circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpp11</span></tt></span> at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x50bce4:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-47393]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a <b><span style="white-space:nowrap"><tt>for</tt></span></b> loop that dereferences a pointer which aliases the loop index. This can result in incorrect behavior when the loop index is indirectly referenced. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-47388]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a loop that contains an <b><span style="white-space:nowrap"><tt>if</tt></span></b> statement where one or more substatements at the start of both the <b><span style="white-space:nowrap"><tt>if</tt></span></b> and <b><span style="white-space:nowrap"><tt>else</tt></span></b> blocks each contain one of:</p>
<ul>
    <li>A bitwise shift compound assignment operator, <span style="white-space:nowrap"><tt>&gt;&gt;=</tt></span>.</li>
    <li>A division compound assignment operator, <span style="white-space:nowrap"><tt>/=</tt></span>.</li>
</ul>


<p>This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-47142]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, the compiler could generate incorrect code for a function that twice loads an 8&#45;bit or 16&#45;bit value from the same location into a wider integer type, and treats the loaded value as signed for one load and unsigned for the other load. The compiler could incorrectly always treat the loaded value as signed or unsigned. This has been fixed. </p>
    </li>
    
    <li>
    <p>[SDCOMP-46962]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could incorrectly fail to generate code for an inline assembly statement that contains only <span style="white-space:nowrap"><tt>CPSID</tt></span> or <span style="white-space:nowrap"><tt>CPSIE</tt></span> instructions. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29406]&nbsp;&nbsp;In certain circumstances, when reporting a diagnostic at the expansion point of a macro, the compiler could incorrectly print a newline character instead of the first character of the name of the macro. This has been fixed.</p>
    </li>
    

</ul>

<h5>Linker (armlink)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-48776]&nbsp;&nbsp;In rare circumstances, when linking a program that contains both A32 and T32 functions, the linker could incorrectly replace an A32 branch instruction with an instruction that is <span style="white-space:nowrap"><tt>UNPREDICTABLE</tt></span> in A32 state when inlining a small T32 function. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-47276]&nbsp;&nbsp;In certain circumstances, the linker unused section elimination mechanism could incorrectly remove sections that are only referred to using their linker&#45;defined input section symbols. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-47224]&nbsp;&nbsp;In certain circumstances, the linker could resolve references to symbols incorrectly when the program contains <span style="white-space:nowrap"><tt>&#95;&#95;at</tt></span> sections. This could result in an affected program accessing an incorrect memory location, or executing code at an unexpected address. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29653]&nbsp;&nbsp;When linking with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;edit</span></tt></span> and a steering file that contains the command <span style="white-space:nowrap"><tt>HIDE</tt></span> <span style="white-space:nowrap"><tt>&#95;&#95;scatterload&#95;rt&#95;thumb&#95;only</tt></span>, the linker incorrectly failed to hide the symbol <span style="white-space:nowrap"><tt>&#95;&#95;scatterload&#95;rt&#95;thumb&#95;only</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-22630]&nbsp;&nbsp;In certain circumstances, when two or more <span style="white-space:nowrap"><tt>&#95;&#95;at</tt></span> sections containing read&#45;write data are placed within an execution region that also contains at least one read&#45;only section, the linker could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0xc0fbf2:&lt;ver&gt;]</tt></span> or <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0xd6a969:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    

</ul>

<h5>Libraries</h5>
<ul>

    
    <li>
    <p>[SDCOMP-45990]&nbsp;&nbsp;In certain circumstances, when using the Arm C library function <span style="white-space:nowrap"><tt>vsscanf&#40;&#41;</tt></span> with a constant format string, a defect in the Arm C library could result in the linker reporting <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>L6218E:</tt></span> <span style="white-space:nowrap"><tt>Undefined</tt></span> <span style="white-space:nowrap"><tt>symbol</tt></span> <span style="white-space:nowrap"><tt>&#95;&#95;0vsscanf</tt></span>. This has been fixed.</p>
    </li>
    

</ul>

<h5>Fromelf</h5>
<ul>

    
    <li>
    <p>[SDCOMP-48404]&nbsp;&nbsp;When decoding exception table information for executable images with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;c</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;e</span></tt></span>, or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;text</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;c</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;e</span></tt></span>, the <span style="white-space:nowrap"><tt>fromelf</tt></span> utility would report incorrect symbol name and address information for <span style="white-space:nowrap"><tt>ARM&#95;EXIDX</tt></span> table entries that refer to a symbol in a different ELF section than the ELF section containing the <span style="white-space:nowrap"><tt>ARM&#95;EXIDX</tt></span> table. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-48381]&nbsp;&nbsp;When producing disassembly with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;c</span></tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;emit</span>=code</tt></span>, or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;text</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;c</span></tt></span>, the <span style="white-space:nowrap"><tt>fromelf</tt></span> utility would report an incorrect load value for a PC&#45;relative load or store instruction that has a relocation. This has been fixed.</p>
    </li>
    

</ul>

<h5>Other issues</h5>
<ul>

    
    <li>
    <p>[SDCOMP-49019]&nbsp;&nbsp;In certain circumstances, when an assembler, compiler, or linker process invoked another of the tools as a sub&#45;process but all suitable licenses were already in use, the processes could deadlock. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-48808]&nbsp;&nbsp;In certain circumstances, when using 32&#45;bit binaries on a Linux host platform and a filesystem that has 64&#45;bit inodes enabled, the tools could incorrectly report <span style="white-space:nowrap"><tt>Unable</tt></span> <span style="white-space:nowrap"><tt>to</tt></span> <span style="white-space:nowrap"><tt>determine</tt></span> <span style="white-space:nowrap"><tt>the</tt></span> <span style="white-space:nowrap"><tt>current</tt></span> <span style="white-space:nowrap"><tt>toolkit.</tt></span> <span style="white-space:nowrap"><tt>Check</tt></span> <span style="white-space:nowrap"><tt>that</tt></span> <span style="white-space:nowrap"><tt>ARM&#95;TOOL&#95;VARIANT</tt></span> <span style="white-space:nowrap"><tt>is</tt></span> <span style="white-space:nowrap"><tt>set</tt></span> <span style="white-space:nowrap"><tt>correctly.</tt></span> <span style="white-space:nowrap"><tt>ARM</tt></span> <span style="white-space:nowrap"><tt>Compiler</tt></span> <span style="white-space:nowrap"><tt>could</tt></span> <span style="white-space:nowrap"><tt>not</tt></span> <span style="white-space:nowrap"><tt>determine</tt></span> <span style="white-space:nowrap"><tt>the</tt></span> <span style="white-space:nowrap"><tt>product</tt></span> <span style="white-space:nowrap"><tt>installation</tt></span> <span style="white-space:nowrap"><tt>it</tt></span> <span style="white-space:nowrap"><tt>is</tt></span> <span style="white-space:nowrap"><tt>part</tt></span> <span style="white-space:nowrap"><tt>of</tt></span>. This has been fixed.</p>
    </li>
    

</ul>








<h3>Changes in Arm Compiler 5.06 update 5</h3>




<h4>General changes in Arm Compiler 5.06 update 5</h4>


<ul>

    
    <li>
    <p>[SDCOMP-46762]&nbsp;&nbsp;Arm Compiler 5.06 update 5 includes FlexNet Publisher 11.14.1.0 client libraries. This version of the license client is not compatible with previous versions of the FlexNet Publisher license server software. When used with a license server running an <span style="white-space:nowrap"><tt>armlmd</tt></span> or <span style="white-space:nowrap"><tt>lmgrd</tt></span> version earlier than 11.14.1.0, Arm Compiler 5.06 update 5 can report either of the following:</p>
<ul>
    <li><span style="white-space:nowrap"><tt>Failed</tt></span> <span style="white-space:nowrap"><tt>to</tt></span> <span style="white-space:nowrap"><tt>check</tt></span> <span style="white-space:nowrap"><tt>out</tt></span> <span style="white-space:nowrap"><tt>a</tt></span> <span style="white-space:nowrap"><tt>license.Bad</tt></span> <span style="white-space:nowrap"><tt>message</tt></span> <span style="white-space:nowrap"><tt>command</tt></span>.</li>
    <li><span style="white-space:nowrap"><tt>Failed</tt></span> <span style="white-space:nowrap"><tt>to</tt></span> <span style="white-space:nowrap"><tt>check</tt></span> <span style="white-space:nowrap"><tt>out</tt></span> <span style="white-space:nowrap"><tt>a</tt></span> <span style="white-space:nowrap"><tt>license.Version</tt></span> <span style="white-space:nowrap"><tt>of</tt></span> <span style="white-space:nowrap"><tt>vendor</tt></span> <span style="white-space:nowrap"><tt>daemon</tt></span> <span style="white-space:nowrap"><tt>is</tt></span> <span style="white-space:nowrap"><tt>too</tt></span> <span style="white-space:nowrap"><tt>old</tt></span>.</li>
    <li><span style="white-space:nowrap"><tt>Flex</tt></span> <span style="white-space:nowrap"><tt>error</tt></span> <span style="white-space:nowrap"><tt>code:</tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">-83</span></tt></span>.</li>
    <li><span style="white-space:nowrap"><tt>Flex</tt></span> <span style="white-space:nowrap"><tt>error</tt></span> <span style="white-space:nowrap"><tt>code:</tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">-140</span></tt></span>.</li>
</ul>


<p>A license server running <span style="white-space:nowrap"><tt>armlmd</tt></span> and <span style="white-space:nowrap"><tt>lmgrd</tt></span> version 11.14.1.0 (or later) is compatible with Arm Compiler 5.06 update 5 and all previous releases of Arm tools. </p>

<p>Arm recommends that you always use the latest version of the license server software that is available from <a href="https://developer.arm.com/products/software-development-tools/license-management/downloads" class="external-link" rel="nofollow">https://developer.arm.com/products/software-development-tools/license-management/downloads</a>.</p>
    </li>
    

</ul>



<h4>Defect fixes in Arm Compiler 5.06 update 5</h4>



<h5>Compiler (armcc)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-46912]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code when a loop dereferences a pointer that aliases a variable used in the controlling expression of that loop. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-46817]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, the compiler could generate incorrect code when inlining a function that returns a <b><span style="white-space:nowrap"><tt>long</tt></span></b> <b><span style="white-space:nowrap"><tt>long</tt></span></b> or <b><span style="white-space:nowrap"><tt>unsigned</tt></span></b> <b><span style="white-space:nowrap"><tt>long</tt></span></b> <b><span style="white-space:nowrap"><tt>long</tt></span></b> into a function that uses a large amount of stack space. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-46807]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code when a loop contains an assignment to a variable of <b><span style="white-space:nowrap"><tt>struct</tt></span></b> type, and the last member of that <b><span style="white-space:nowrap"><tt>struct</tt></span></b> type is an unnamed bitfield of width <span style="white-space:nowrap"><tt>0</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-46795]&nbsp;&nbsp;The compiler would incorrectly accept floating&#45;point literals that are greater than <span style="white-space:nowrap"><tt>DBL&#95;MAX</tt></span> &#40;<span style="white-space:nowrap"><tt>1.79769313486231571e&#43;308</tt></span>&#41; but less than <span style="white-space:nowrap"><tt>1.0e&#43;309</tt></span>, and then represent them as the floating&#45;point value <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;0.0</span></tt></span>. This has been fixed. The compiler now reports <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#30:</tt></span> <span style="white-space:nowrap"><tt>floating</tt></span> <span style="white-space:nowrap"><tt>constant</tt></span> <span style="white-space:nowrap"><tt>is</tt></span> <span style="white-space:nowrap"><tt>out</tt></span> <span style="white-space:nowrap"><tt>of</tt></span> <span style="white-space:nowrap"><tt>range</tt></span>.</p>
    </li>
    
    <li>
    <p>[SDCOMP-46767]&nbsp;&nbsp;When compiling a constructor that initializes an array using a C&#43;&#43;11 braced&#45;init&#45;list, the compiler would report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x87ecef:&lt;ver&gt;]</tt></span> or a Windows <span style="white-space:nowrap"><tt>APPCRASH</tt></span> error. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-46700]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, the compiler could generate incorrect code for a compound&#45;assignment statement that modifies two members of the same <b><span style="white-space:nowrap"><tt>struct</tt></span></b>, a memory location contains both those members, and at least one of those members is a bitfield. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-46535]&nbsp;&nbsp;When compiling C&#43;&#43;11 code containing a lambda, where the lambda capture list includes an object passed by value and that object has a non&#45;trivial destructor, the compiler would report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x21315f:&lt;ver&gt;]</tt></span> or a Windows <span style="white-space:nowrap"><tt>APPCRASH</tt></span> error. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45940]&nbsp;&nbsp;The compiler would incorrectly accept code which passes a <span style="white-space:nowrap"><tt>&#95;&#95;packed</tt></span> pointer as an argument to a function that has been declared implicitly, or declared without argument types. This has been fixed. The compiler now reports <span style="white-space:nowrap"><tt>Error:</tt></span>  <span style="white-space:nowrap"><tt>#3734:</tt></span> <span style="white-space:nowrap"><tt>&#95;&#95;packed</tt></span> <span style="white-space:nowrap"><tt>qualifier</tt></span> <span style="white-space:nowrap"><tt>dropped</tt></span> <span style="white-space:nowrap"><tt>when</tt></span> <span style="white-space:nowrap"><tt>passing</tt></span> <span style="white-space:nowrap"><tt>argument</tt></span> <span style="white-space:nowrap"><tt>to</tt></span> <span style="white-space:nowrap"><tt>unprototyped</tt></span> <span style="white-space:nowrap"><tt>function</tt></span>.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45899]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a loop containing a conditional statement that causes a subsequent conditional <b><span style="white-space:nowrap"><tt>break</tt></span></b> statement within the same loop to be unreachable. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45880]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could generate incorrect code when an assignment expression and a bitwise AND expression are conditionally executed, and the result of the bitwise AND expression is used to conditionally evaluate another expression. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45854]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a loop that refers to the address of a <b><span style="white-space:nowrap"><tt>static</tt></span></b> pointer, modifies the pointer, and then updates memory by dereferencing the pointer. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45833]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code when the controlling expression of a loop contains a variable of type <b><span style="white-space:nowrap"><tt>char</tt></span></b> that must overflow in order to reach the loop termination condition. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45824]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could generate incorrect code when the assignment to, and subsequent use of, a 64&#45;bit integer object both involve a bitwise OR or Exclusive OR with a 64&#45;bit integer constant. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45820]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a loop which calls a function that initializes a local array using the address of a global variable, and subsequently uses the value returned by that function. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45688]&nbsp;&nbsp;When compiling an inline assembler statement in which a destination operand expression is cast to a type with a size smaller than 32 bits, the compiler would incorrectly generate code that performs a 32&#45;bit memory access. This has been fixed.</p>
    </li>
    

</ul>

<h5>Assembler (armasm)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-47141]&nbsp;&nbsp;The assembler would incorrectly accept floating&#45;point literals that are greater than <span style="white-space:nowrap"><tt>1.79769313486231571e&#43;308</tt></span> but less than <span style="white-space:nowrap"><tt>1.0e&#43;309</tt></span>, and then represent them as the floating&#45;point value <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;0.0</span></tt></span>. This has been fixed. The assembler now reports <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>A1407E:</tt></span> <span style="white-space:nowrap"><tt>Overlarge</tt></span> <span style="white-space:nowrap"><tt>floating</tt></span> <span style="white-space:nowrap"><tt>point</tt></span> <span style="white-space:nowrap"><tt>value</tt></span>.</p>
    </li>
    
    <li>
    <p>[SDCOMP-46908]&nbsp;&nbsp;In certain circumstances, when assembling a <span style="white-space:nowrap"><tt>VMOV</tt></span> instruction that has a <span style="white-space:nowrap"><tt>.32</tt></span>, <span style="white-space:nowrap"><tt>.I32</tt></span>, <span style="white-space:nowrap"><tt>.S32</tt></span>, or <span style="white-space:nowrap"><tt>.U32</tt></span> suffix, the assembler could incorrectly report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>A1887E:</tt></span> <span style="white-space:nowrap"><tt>Specified</tt></span> <span style="white-space:nowrap"><tt>source</tt></span> <span style="white-space:nowrap"><tt>data</tt></span> <span style="white-space:nowrap"><tt>type</tt></span> <span style="white-space:nowrap"><tt>not</tt></span> <span style="white-space:nowrap"><tt>allowed;</tt></span> <span style="white-space:nowrap"><tt>must</tt></span> <span style="white-space:nowrap"><tt>be</tt></span> <span style="white-space:nowrap"><tt>one</tt></span> <span style="white-space:nowrap"><tt>of:</tt></span> <span style="white-space:nowrap"><tt>F32</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45076]&nbsp;&nbsp;In certain circumstances, when assembling code containing a conditional instruction with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;unsafe</span></tt></span>, the assembler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x364f5c:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    

</ul>

<h5>Libraries</h5>
<ul>

    
    <li>
    <p>[SDCOMP-47150]&nbsp;&nbsp;In certain circumstances, the Arm Compiler library implementations of <span style="white-space:nowrap"><tt>strtod&#40;&#41;</tt></span> and <span style="white-space:nowrap"><tt>wcstod&#40;&#41;</tt></span> could incorrectly return <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;0.0</span></tt></span> instead of <span style="white-space:nowrap"><tt>inf</tt></span> when the input string specifies a number that lies in the range <span style="white-space:nowrap"><tt>&#40;1.79769313486231571e&#43;308,</tt></span> <span style="white-space:nowrap"><tt>1.0e&#43;309&#41;</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-47048]&nbsp;&nbsp;In rare circumstances, the Arm Compiler library implementation of <span style="white-space:nowrap"><tt>expm1f&#40;&#41;</tt></span> could return an incorrect result when the input argument is between <span style="white-space:nowrap"><tt>0.8110728</tt></span> and <span style="white-space:nowrap"><tt>0.8231074</tt></span>. The result incorrectly did not meet "the 1 unit in the last place &#40;ULP&#41; accuracy requirement" specified by the C standard. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-46050]&nbsp;&nbsp;In certain circumstances, when the program is built for full IEEE 754 floating&#45;point standard conformance, the Arm Compiler library implementations of the following string to floating&#45;point conversion functions could behave incorrectly:</p>
<ul>
    <li><span style="white-space:nowrap"><tt>atof&#40;&#41;</tt></span>.</li>
    <li><span style="white-space:nowrap"><tt>strtod&#40;&#41;</tt></span>.</li>
    <li><span style="white-space:nowrap"><tt>strtof&#40;&#41;</tt></span>.</li>
    <li><span style="white-space:nowrap"><tt>strtold&#40;&#41;</tt></span>.</li>
    <li>The <span style="white-space:nowrap"><tt>scanf&#40;&#41;</tt></span> family of functions when using a floating&#45;point conversion specifier.</li>
</ul>


<p>The affected functions could:</p>
<ul>
    <li>Incorrectly fail to set the IEEE inexact, overflow, or underflow exception flags.</li>
    <li>Incorrectly round the result to <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;0</span></tt></span>, <span style="white-space:nowrap"><tt>0</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;inf</span></tt></span>, or <span style="white-space:nowrap"><tt>inf</tt></span>.</li>
    <li>Set <span style="white-space:nowrap"><tt>errno</tt></span> to <span style="white-space:nowrap"><tt>0</tt></span> when <span style="white-space:nowrap"><tt>ERANGE</tt></span> is expected.</li>
</ul>


<p>This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45329]&nbsp;&nbsp;In rare circumstances, the microlib implementation of the <span style="white-space:nowrap"><tt>printf&#40;&#41;</tt></span> family of functions could incorrectly write <span style="white-space:nowrap"><tt>%%</tt></span> instead of <span style="white-space:nowrap"><tt>%</tt></span> when processing the format conversion specification <span style="white-space:nowrap"><tt>%%</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30369]&nbsp;&nbsp;The Arm Compiler library implementation of <span style="white-space:nowrap"><tt>strtof&#40;&#41;</tt></span> incorrectly failed to set <span style="white-space:nowrap"><tt>errno</tt></span> to <span style="white-space:nowrap"><tt>ERANGE</tt></span> when the number represented by its input string is within range for <b><span style="white-space:nowrap"><tt>double</tt></span></b> but not for <b><span style="white-space:nowrap"><tt>float</tt></span></b>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29945]&nbsp;&nbsp;The Arm Compiler library implementation of <span style="white-space:nowrap"><tt>setlocale&#40;&#41;</tt></span> would incorrectly accept locale strings that begin with the <span style="white-space:nowrap"><tt>*</tt></span> character but have an invalid format, and subsequently update the internal locale state of the C library to contain invalid pointers. This could result in unpredictable run time behavior. This has been fixed.</p>
    </li>
    

</ul>

<h5>Other issues</h5>
<ul>

    
    <li>
    <p>[SDCOMP-29403]&nbsp;&nbsp;In certain circumstances, when using a Linux host platform and a filesystem that has 64&#45;bit inodes enabled, the tools could report either of the following:</p>
<ul>
    <li><span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#5:</tt></span> <span style="white-space:nowrap"><tt>cannot</tt></span> <span style="white-space:nowrap"><tt>open</tt></span> <span style="white-space:nowrap"><tt>&lt;entity&gt;</tt></span> <span style="white-space:nowrap"><tt>input</tt></span> <span style="white-space:nowrap"><tt>file</tt></span> <span style="white-space:nowrap"><tt>"&lt;filename&gt;":</tt></span> <span style="white-space:nowrap"><tt>Value</tt></span> <span style="white-space:nowrap"><tt>too</tt></span> <span style="white-space:nowrap"><tt>large</tt></span> <span style="white-space:nowrap"><tt>for</tt></span> <span style="white-space:nowrap"><tt>defined</tt></span> <span style="white-space:nowrap"><tt>data</tt></span> <span style="white-space:nowrap"><tt>type</tt></span>.</li>
    <li><span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#2918:</tt></span> <span style="white-space:nowrap"><tt>cannot</tt></span> <span style="white-space:nowrap"><tt>open</tt></span> <span style="white-space:nowrap"><tt>&lt;entity&gt;</tt></span> <span style="white-space:nowrap"><tt>file</tt></span> <span style="white-space:nowrap"><tt>"&lt;entity&gt;":</tt></span> <span style="white-space:nowrap"><tt>not</tt></span> <span style="white-space:nowrap"><tt>a</tt></span> <span style="white-space:nowrap"><tt>regular</tt></span> <span style="white-space:nowrap"><tt>file</tt></span>.</li>
</ul>


<p>This has been fixed.</p>
    </li>
    

</ul>






<h3>Changes in Arm Compiler 5.06 update 4</h3>




<h4>General changes in Arm Compiler 5.06 update 4</h4>


<ul>

    
    <li>
    <p>[SDCOMP-22192]&nbsp;&nbsp;The ABI conformance of the tools has been updated to release 2.09 of the 32&#45;bit <em>Application Binary Interface for the Arm Architecture</em>.</p>
    </li>
    

</ul>



<h4>Defect fixes in Arm Compiler 5.06 update 4</h4>



<h5>Compiler (armcc)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-45708]&nbsp;&nbsp;When compiling C&#43;&#43;11 code with exceptions disabled, the compiler would incorrectly generate code that fails to call the destructors when deleting objects of type <b><span style="white-space:nowrap"><tt>class</tt></span></b> or <b><span style="white-space:nowrap"><tt>struct</tt></span></b> that have been initialized using brace initializers. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45545]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, the compiler could generate incorrect code when a constant value is written to a variable in a compound expression. This would result in an incorrect value being written to the variable. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45522]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a <b><span style="white-space:nowrap"><tt>for</tt></span></b> loop that dereferences a pointer which aliases the loop index. This could result in incorrect behavior when the loop index is indirectly referenced. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45519]&nbsp;&nbsp;In certain circumstances, when compiling an expression that modifies at least two bitfield members of the same <b><span style="white-space:nowrap"><tt>struct</tt></span></b>, at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, the compiler could incorrectly generate code that does not update all of the modified bitfield members. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45508]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a <b><span style="white-space:nowrap"><tt>for</tt></span></b> loop that calls a function where one of the arguments involves a comma operator with a right&#45;hand operand that requires an implicit integer conversion. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45489]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could generate incorrect code when both the operands of a logical OR expression access the same non&#45;volatile variable and at least one of the operands is an expression that has side&#45;effects. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45484]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, the compiler could generate incorrect code when integer constants that have the same binary representation appear in at least two expressions, and the constant can be implicitly converted to a narrower integer type in a subset of those expressions without changing the behavior. The compiler could incorrectly use a narrower version of the constant in expressions that require the full value, resulting in incorrect behavior. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45478]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could incorrectly generate a sequence of code containing conditional and flag&#45;setting instructions that does not conform to the source code. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44744]&nbsp;&nbsp;In rare circumstances, when compiling code which passes an argument that is an element of a multi&#45;dimensional array to a function parameter of <b><span style="white-space:nowrap"><tt>union</tt></span></b> type, at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could incorrectly report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#167:</tt></span> <span style="white-space:nowrap"><tt>argument</tt></span> <span style="white-space:nowrap"><tt>of</tt></span> <span style="white-space:nowrap"><tt>type</tt></span> <span style="white-space:nowrap"><tt>&lt;type&gt;</tt></span> <span style="white-space:nowrap"><tt>is</tt></span> <span style="white-space:nowrap"><tt>incompatible</tt></span> <span style="white-space:nowrap"><tt>with</tt></span> <span style="white-space:nowrap"><tt>parameter</tt></span> <span style="white-space:nowrap"><tt>of</tt></span> <span style="white-space:nowrap"><tt>type</tt></span> <span style="white-space:nowrap"><tt>&lt;type&gt;</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29087]&nbsp;&nbsp;In rare circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpp11</span></tt></span> at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span>, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x50bce4:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25441]&nbsp;&nbsp;In certain circumstances, when the language was other than English, and the source locale was not set to UTF&#45;8, the compiler could report incorrect error messages. This has been fixed.</p>
    </li>
    

</ul>

<h5>Linker (armlink)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-30572]&nbsp;&nbsp;When linking a program without the <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span></tt></span> option and the <em>input&#45;file&#45;list</em> only specifies members of libraries, the linker would report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x4b0af3:&lt;ver&gt;]</tt></span> or <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0xec6eb7:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    

</ul>

<h5>Libraries</h5>
<ul>

    
    <li>
    <p>[SDCOMP-25153]&nbsp;&nbsp;The Arm Compiler library implementations of the following functions for Armv6&#45;M targets would return an incorrect result when the input string specifies a number that is too large to represent as a <b><span style="white-space:nowrap"><tt>double</tt></span></b>, including when the output type is <b><span style="white-space:nowrap"><tt>float</tt></span></b>:</p>
<ul>
    <li><span style="white-space:nowrap"><tt>atof&#40;&#41;</tt></span>.</li>
    <li><span style="white-space:nowrap"><tt>strtod&#40;&#41;</tt></span>.</li>
    <li><span style="white-space:nowrap"><tt>strtof&#40;&#41;</tt></span>.</li>
    <li><span style="white-space:nowrap"><tt>strtold&#40;&#41;</tt></span>.</li>
    <li>The <span style="white-space:nowrap"><tt>scanf&#40;&#41;</tt></span> family of functions when using a floating&#45;point conversion specifier.</li>
</ul>


<p>In these circumstances, the following functions would also incorrectly fail to set <span style="white-space:nowrap"><tt>errno</tt></span> to <span style="white-space:nowrap"><tt>ERANGE</tt></span>:</p>
<ul>
    <li><span style="white-space:nowrap"><tt>strtod&#40;&#41;</tt></span>.</li>
    <li><span style="white-space:nowrap"><tt>strtof&#40;&#41;</tt></span>.</li>
    <li><span style="white-space:nowrap"><tt>strtold&#40;&#41;</tt></span>.</li>
    <li>The <span style="white-space:nowrap"><tt>scanf&#40;&#41;</tt></span> family of functions when using a floating&#45;point conversion specifier.</li>
</ul>


<p>This has been fixed.</p>
    </li>
    

</ul>

<h5>Other issues</h5>
<ul>

    
    <li>
    <p>[SDCOMP-45568]&nbsp;&nbsp;When integrating Arm Compiler into Keil MDK with a 7-day evaluation license, the tools would incorrectly report <span style="white-space:nowrap"><tt>FLEX&#95;USE</tt></span> <span style="white-space:nowrap"><tt>is</tt></span> <span style="white-space:nowrap"><tt>set</tt></span> <span style="white-space:nowrap"><tt>to</tt></span> <span style="white-space:nowrap"><tt>1</tt></span> <span style="white-space:nowrap"><tt>in</tt></span> <span style="white-space:nowrap"><tt>C:\Keil\tools.ini</tt></span> <span style="white-space:nowrap"><tt>but</tt></span> <span style="white-space:nowrap"><tt>no</tt></span> <span style="white-space:nowrap"><tt>FLEX=port@host</tt></span> <span style="white-space:nowrap"><tt>is</tt></span> <span style="white-space:nowrap"><tt>defined</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-45297]&nbsp;&nbsp;The tools would generate objects that incorrectly claimed conformance to release 2.10 rather than release 2.09 of the 32&#45;bit <em>Application Binary Interface for the Arm Architecture</em>. This has been fixed.</p>
    </li>
    

</ul>






<h3>Changes in Arm Compiler 5.06 update 3</h3>




<h4>General changes in Arm Compiler 5.06 update 3</h4>


<ul>

    
    <li>
    <p>[SDCOMP-45000]&nbsp;&nbsp;Support for the following processors has been removed:</p>
<ul>
    <li>88FR101.</li>
    <li>88FR101.hw&#95;divide.</li>
    <li>88FR111.</li>
    <li>88FR111.no&#95;hw&#95;divide.</li>
    <li>88FR121.</li>
    <li>88FR121.hw&#95;divide.</li>
    <li>88FR131.</li>
    <li>88FR131.hw&#95;divide.</li>
    <li>88FR301.</li>
    <li>88FR301.hw&#95;divide.</li>
    <li>88FR321.</li>
    <li>88FR321.hw&#95;divide.</li>
    <li>88FR331.</li>
    <li>88FR331.hw&#95;divide.</li>
    <li>Arm710T.</li>
    <li>Arm740T.</li>
    <li>Arm7TDM.</li>
    <li>Arm7TM.</li>
    <li>Arm7TM&#45;S.</li>
    <li>Arm810.</li>
    <li>Arm940T.</li>
    <li>Arm968E&#45;S.</li>
    <li>Arm9EJ&#45;S.</li>
    <li>Arm1022E.</li>
    <li>Arm1026EJ&#45;S.</li>
    <li>Arm1156T2F&#45;S.</li>
    <li>SA&#45;110.</li>
    <li>SA&#45;1100.</li>
</ul>


<p>Replace affected <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=<em>name</em></tt></span> options as follows:</p>
<ul>
    <li>Use <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=4</tt></span> instead of <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM810</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=SA&#45;110</tt></span>, or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=SA&#45;1100</tt></span>.</li>
    <li>Use <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM7TDMI</tt></span> instead of <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM710T</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM740T</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM7TDM</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM7TM</tt></span>, or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM7TM&#45;S</tt></span>.</li>
    <li>Use <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM9TDMI</tt></span> instead of <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM940T</tt></span>.</li>
    <li>Use <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=5TE</tt></span> instead of <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR101</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR101.hw&#95;divide</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR111</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR111.no&#95;hw&#95;divide</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR121</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR121.hw&#95;divide</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR131</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR131.hw&#95;divide</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR301</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR301.hw&#95;divide</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR321</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR321.hw&#95;divide</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR331</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR331.hw&#95;divide</tt></span>, or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM968E&#45;S</tt></span>.</li>
    <li>Use <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=5TEJ</tt></span> instead of <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM9EJ&#45;S</tt></span>.</li>
    <li>Use <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM1020E</tt></span> instead of <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM1022E</tt></span> or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM1026EJ&#45;S</tt></span>.</li>
    <li>Use <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM1156T2&#45;S</tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;fpu</span>=VFPv2</tt></span> instead of <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM1156T2F&#45;S</tt></span>.</li>
</ul><p></p>
    </li>
    
    <li>
    <p>[SDCOMP-45022]&nbsp;&nbsp;Support has been added for the Cortex&#45;R8 processor. To target Cortex&#45;R8, use the following option:</p>
<ul>
    <li><span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=Cortex&#45;R8</tt></span></li>
</ul><p></p>
    </li>
    

</ul>



<h4>Defect fixes in Arm Compiler 5.06 update 3</h4>



<h5>Compiler (armcc)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-45004]&nbsp;&nbsp;In certain circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a repeated and necessary statement. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44793]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a loop as a result of ignoring a loop&#45;carried dependency on the iteration variable. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44774]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span>, the compiler could generate incorrect code which fails to update the value of a global variable that is modified within a nested loop. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44765]&nbsp;&nbsp;In rare circumstances, when compiling for T32 state for a target that supports Thumb&#45;2 technology, the compiler could generate a sequence of code in which a <span style="white-space:nowrap"><tt>CMP</tt></span> instruction incorrectly appeared before another flag&#45;setting instruction. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44757]&nbsp;&nbsp;In certain circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;bi</span></tt></span> or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;bigend</span></tt></span> at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">-O1</span></tt></span> or above, the compiler could generate an incorrect result when sign&#45;extending an expression involving a bitfield member of a <b><span style="white-space:nowrap"><tt>struct</tt></span></b>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44753]&nbsp;&nbsp;When compiling for a target that does not support bit&#45;banding, the compiler would incorrectly accept the <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;bitband</span></tt></span> option. This has been fixed. The compiler now reports <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>C4368W:</tt></span> <span style="white-space:nowrap"><tt>Selected</tt></span> <span style="white-space:nowrap"><tt>target</tt></span> <span style="white-space:nowrap"><tt>does</tt></span> <span style="white-space:nowrap"><tt>not</tt></span> <span style="white-space:nowrap"><tt>support</tt></span> <span style="white-space:nowrap"><tt>bit&#45;banding</tt></span>.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44696]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">-Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code that resulted in a failure to enter a loop body. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44676]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a nested loop. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44669]&nbsp;&nbsp;The compiler would generate incorrect code for C&#43;&#43;11 abstract classes that use delegated constructors. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44621]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, the compiler could generate incorrect code for accesses to a function argument that is aliased by a pointer. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44618]&nbsp;&nbsp;In rare circumstances, the compiler could generate incorrect code after emitting an <span style="white-space:nowrap"><tt>LDRD</tt></span> or <span style="white-space:nowrap"><tt>STRD</tt></span> instruction with writeback. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44601]&nbsp;&nbsp;In rare circumstances, when compiling for T32 state, the compiler could generate incorrect code for a relational expression that involves an increment operator or decrement operator. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44594]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could generate incorrect code for functions that are passed a <b><span style="white-space:nowrap"><tt>struct</tt></span></b> by value containing at least one bitfield narrower than 32 bits. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44583]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span>, the compiler could generate incorrect code that unconditionally assigns a value to a variable that should have been assigned conditionally. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44581]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code when evaluating a parameter to a function call that is contained in the controlling expression of an <b><span style="white-space:nowrap"><tt>if</tt></span></b> statement. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44559]&nbsp;&nbsp;In rare circumstances, when compiling for T32 state, the compiler could generate incorrect code for a function that contains two conditional expressions with the same condition. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44523]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a multiplication that may overflow and involves integers of different types or widths. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-44469]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, the compiler could generate incorrect code for functions that access the CPSR. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30951]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, the compiler could generate incorrect code for a program that writes a negative value to a structure using <span style="white-space:nowrap"><tt>memset&#40;&#41;</tt></span> and then accesses that structure. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30950]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, the compiler could incorrectly generate a tail call to <span style="white-space:nowrap"><tt>memcpy&#40;&#41;</tt></span> with a pointer argument that pointed below the stack pointer. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30854]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">-Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a loop that has an iteration variable of unsigned integer type. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30847]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a loop that accesses a <b><span style="white-space:nowrap"><tt>volatile</tt></span></b> member of a <b><span style="white-space:nowrap"><tt>struct</tt></span></b>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30818]&nbsp;&nbsp;In certain circumstances, when compiling for T32 state for a target that does not support Thumb&#45;2 technology, use of the <span style="white-space:nowrap"><tt>alloca&#40;&#41;</tt></span> function could cause the compiler to report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0xcbb629:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29863]&nbsp;&nbsp;In certain circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;multifile</span></tt></span>, the compiler could incorrectly report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#3167:</tt></span> <span style="white-space:nowrap"><tt>attribute</tt></span> <span style="white-space:nowrap"><tt>"at"</tt></span> <span style="white-space:nowrap"><tt>is</tt></span> <span style="white-space:nowrap"><tt>missing</tt></span> <span style="white-space:nowrap"><tt>in</tt></span> <span style="white-space:nowrap"><tt>another</tt></span> <span style="white-space:nowrap"><tt>translation</tt></span> <span style="white-space:nowrap"><tt>unit</tt></span> if the same variable is declared in multiple translation units and <span style="white-space:nowrap"><tt>&#95;&#95;attribute&#95;&#95;&#40;&#40;at&#40;address&#41;&#41;&#41;</tt></span> is used in at least one but not all of the declarations. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29651]&nbsp;&nbsp;In certain circumstances, when compiling C&#43;&#43; code containing a function template that uses a non&#45;type template parameter in a call to an intrinsic, the compiler could incorrectly report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#2529:</tt></span> <span style="white-space:nowrap"><tt>expression</tt></span> <span style="white-space:nowrap"><tt>must</tt></span> <span style="white-space:nowrap"><tt>be</tt></span> <span style="white-space:nowrap"><tt>an</tt></span> <span style="white-space:nowrap"><tt>integral</tt></span> <span style="white-space:nowrap"><tt>constant</tt></span> <span style="white-space:nowrap"><tt>in</tt></span> <span style="white-space:nowrap"><tt>range</tt></span> <span style="white-space:nowrap"><tt>&lt;entity&gt;</tt></span> <span style="white-space:nowrap"><tt>to</tt></span> <span style="white-space:nowrap"><tt>&lt;entity&gt;</tt></span> for valid values of the parameter. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29350]&nbsp;&nbsp;When compiling C&#43;&#43;11 code containing a range&#45;based <b><span style="white-space:nowrap"><tt>for</tt></span></b> loop where the iteration variable is not used in the loop body, the compiler would report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x6bca8b:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-11935]&nbsp;&nbsp;When compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;fpu</span>=vfpv2</tt></span> or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;fpu</span>=softvfp&#43;vfpv2</tt></span> for an Armv7&#45;A target that supports NEON, the compiler would generate code that could incorrectly contain VFPv3 or later instructions. This has been fixed.</p>
    </li>
    

</ul>

<h5>Assembler (armasm)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-44881]&nbsp;&nbsp;When assembling <span style="white-space:nowrap"><tt>VMRS</tt></span> or <span style="white-space:nowrap"><tt>VMSR</tt></span> instructions for an Armv7E&#45;M target that supports a hardware floating-point unit, the assembler would incorrectly accept system registers other than <span style="white-space:nowrap"><tt>FPSCR</tt></span>. This has been fixed. The assembler now reports <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>A1477E:</tt></span> <span style="white-space:nowrap"><tt>This</tt></span> <span style="white-space:nowrap"><tt>register</tt></span> <span style="white-space:nowrap"><tt>combination</tt></span> <span style="white-space:nowrap"><tt>results</tt></span> <span style="white-space:nowrap"><tt>in</tt></span> <span style="white-space:nowrap"><tt>UNPREDICTABLE</tt></span> <span style="white-space:nowrap"><tt>behaviour</tt></span>.</p>
    </li>
    
    <li>
    <p>[SDCOMP-22681]&nbsp;&nbsp;When assembling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;fpu</span>=vfpv2</tt></span> or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;fpu</span>=softvfp&#43;vfpv2</tt></span> for an Armv7&#45;A target that supports NEON, the assembler would incorrectly fail to report an error for the usage of VFPv3 or later instructions in the source code. This has been fixed. The assembler now reports <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>A1797E:</tt></span> <span style="white-space:nowrap"><tt>Specified</tt></span> <span style="white-space:nowrap"><tt>FPU</tt></span> <span style="white-space:nowrap"><tt>is</tt></span> <span style="white-space:nowrap"><tt>not</tt></span> <span style="white-space:nowrap"><tt>compatible</tt></span> <span style="white-space:nowrap"><tt>with</tt></span> <span style="white-space:nowrap"><tt>CPU</tt></span> <span style="white-space:nowrap"><tt>architecture</tt></span>.</p>
    </li>
    

</ul>

<h5>Linker (armlink)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-30022]&nbsp;&nbsp;When preprocessing a scatter&#45;file on Windows, the linker would fail to expand any environment variables specified using <span style="white-space:nowrap"><tt>%&lt;NAME&gt;%</tt></span> syntax in the <span style="white-space:nowrap"><tt>#!</tt></span> line before invoking the selected preprocessor. This has been fixed.</p>
    </li>
    

</ul>

<h5>Libraries</h5>
<ul>

    
    <li>
    <p>[SDCOMP-32959]&nbsp;&nbsp;In rare circumstances, printing a <b><span style="white-space:nowrap"><tt>long</tt></span></b> <b><span style="white-space:nowrap"><tt>double</tt></span></b> value using the microlib implementation of the <span style="white-space:nowrap"><tt>printf&#40;&#41;</tt></span> function could result in an infinite loop. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30944]&nbsp;&nbsp;The microlib implementations of the <span style="white-space:nowrap"><tt>snprintf&#40;&#41;</tt></span> and <span style="white-space:nowrap"><tt>vsnprintf&#40;&#41;</tt></span> functions would incorrectly attempt to write to their output pointer when passed a length of zero. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30381]&nbsp;&nbsp;In rare circumstances, the standard C library and microlib implementations of the <span style="white-space:nowrap"><tt>expm1f&#40;&#41;</tt></span> function could return an incorrect result. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-23349]&nbsp;&nbsp;The microlib implementation of the <span style="white-space:nowrap"><tt>fclose&#40;&#41;</tt></span> function selected by <span style="white-space:nowrap"><tt>#pragma</tt></span> <span style="white-space:nowrap"><tt>import</tt></span> <span style="white-space:nowrap"><tt>&#40;&#95;&#95;use&#95;full&#95;stdio&#41;</tt></span> would incorrectly fail to free the memory allocated for the <span style="white-space:nowrap"><tt>FILE</tt></span> structure by <span style="white-space:nowrap"><tt>fopen&#40;&#41;</tt></span>. This could result in a memory leak. This has been fixed.</p>
    </li>
    

</ul>






<h3>Changes in Arm Compiler 5.06 update 2</h3>




<h4>Enhancements in Arm Compiler 5.06 update 2</h4>



<h5>Linker (armlink)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-30794]&nbsp;&nbsp;Support has been added for the <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;no</span>&#95;unaligned&#95;access</tt></span> linker option. This option prevents the linker from selecting objects from the Arm C library that permit unaligned accesses, and causes the linker to report one or more of the following downgradeable errors if any input object permits unaligned accesses:</p>
<ul>
    <li><span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>L6366E:</tt></span> <span style="white-space:nowrap"><tt>&lt;object&gt;</tt></span> <span style="white-space:nowrap"><tt>attributes&lt;attr&gt;</tt></span> <span style="white-space:nowrap"><tt>are</tt></span> <span style="white-space:nowrap"><tt>not</tt></span> <span style="white-space:nowrap"><tt>compatible</tt></span> <span style="white-space:nowrap"><tt>with</tt></span> <span style="white-space:nowrap"><tt>the</tt></span> <span style="white-space:nowrap"><tt>provided</tt></span> <span style="white-space:nowrap"><tt>cpu</tt></span> <span style="white-space:nowrap"><tt>and</tt></span> <span style="white-space:nowrap"><tt>fpu</tt></span> <span style="white-space:nowrap"><tt>attributes</tt></span>.</li>
    <li><span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>L6367E:</tt></span> <span style="white-space:nowrap"><tt>&lt;object&gt;&#40;&lt;section&gt;&#41;</tt></span> <span style="white-space:nowrap"><tt>attributes&lt;attr&gt;</tt></span> <span style="white-space:nowrap"><tt>are</tt></span> <span style="white-space:nowrap"><tt>not</tt></span> <span style="white-space:nowrap"><tt>compatible</tt></span> <span style="white-space:nowrap"><tt>with</tt></span> <span style="white-space:nowrap"><tt>the</tt></span> <span style="white-space:nowrap"><tt>provided</tt></span> <span style="white-space:nowrap"><tt>cpu</tt></span> <span style="white-space:nowrap"><tt>and</tt></span> <span style="white-space:nowrap"><tt>fpu</tt></span> <span style="white-space:nowrap"><tt>attributes</tt></span>.</li>
    <li><span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>L6368E:</tt></span> <span style="white-space:nowrap"><tt>&lt;symbol&gt;</tt></span> <span style="white-space:nowrap"><tt>defined</tt></span> <span style="white-space:nowrap"><tt>in</tt></span> <span style="white-space:nowrap"><tt>&lt;object&gt;&#40;&lt;section&gt;&#41;</tt></span> <span style="white-space:nowrap"><tt>attributes&lt;attr&gt;</tt></span> <span style="white-space:nowrap"><tt>are</tt></span> <span style="white-space:nowrap"><tt>not</tt></span> <span style="white-space:nowrap"><tt>compatible</tt></span> <span style="white-space:nowrap"><tt>with</tt></span> <span style="white-space:nowrap"><tt>the</tt></span> <span style="white-space:nowrap"><tt>provided</tt></span> <span style="white-space:nowrap"><tt>cpu</tt></span> <span style="white-space:nowrap"><tt>and</tt></span> <span style="white-space:nowrap"><tt>fpu</tt></span> <span style="white-space:nowrap"><tt>attributes</tt></span>.</li>
</ul><p></p>
    </li>
    

</ul>




<h4>Defect fixes in Arm Compiler 5.06 update 2</h4>



<h5>Compiler (armcc)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-30645]&nbsp;&nbsp;In rare circumstances, when compiling expressions that only need to be evaluated due to side&#45;effects such as <b><span style="white-space:nowrap"><tt>volatile</tt></span></b> accesses or function calls, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0xcddbd6:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30601]&nbsp;&nbsp;In rare circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span> at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could incorrectly report <span style="white-space:nowrap"><tt>"no</tt></span> <span style="white-space:nowrap"><tt>source":</tt></span> <span style="white-space:nowrap"><tt>Warning:</tt></span> <span style="white-space:nowrap"><tt>#68&#45;D:</tt></span> <span style="white-space:nowrap"><tt>integer</tt></span> <span style="white-space:nowrap"><tt>conversion</tt></span> <span style="white-space:nowrap"><tt>resulted</tt></span> <span style="white-space:nowrap"><tt>in</tt></span> <span style="white-space:nowrap"><tt>a</tt></span> <span style="white-space:nowrap"><tt>change</tt></span> <span style="white-space:nowrap"><tt>of</tt></span> <span style="white-space:nowrap"><tt>sign</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30568]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a multiplication that may overflow and involves integers of different types or widths. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30556]&nbsp;&nbsp;In certain circumstances, when compiling C&#43;&#43; code containing an expression of the form <span style="white-space:nowrap"><tt>&lt;condition&gt;</tt></span> <span style="white-space:nowrap"><tt>?</tt></span> <span style="white-space:nowrap"><tt>&lt;expression1&gt;</tt></span> <span style="white-space:nowrap"><tt>:</tt></span> <span style="white-space:nowrap"><tt>&lt;expression2&gt;</tt></span> where <span style="white-space:nowrap"><tt>&lt;condition&gt;</tt></span> is a constant known at compile time and both <span style="white-space:nowrap"><tt>&lt;expression1&gt;</tt></span> and <span style="white-space:nowrap"><tt>&lt;expression2&gt;</tt></span> return class rvalues, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x87ecef:&lt;ver&gt;]</tt></span> or a Windows <span style="white-space:nowrap"><tt>APPCRASH</tt></span> error. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30412]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x691cf6:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30374]&nbsp;&nbsp;When compiling C&#43;&#43;11 code containing the type <span style="white-space:nowrap"><tt>std::nullptr&#95;t</tt></span> with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;omf</span>&#95;browse</tt></span>, the compiler would incorrectly report <span style="white-space:nowrap"><tt>KB:</tt></span> <span style="white-space:nowrap"><tt>Unexpected</tt></span> <span style="white-space:nowrap"><tt>type:</tt></span> <span style="white-space:nowrap"><tt>16</tt></span> <span style="white-space:nowrap"><tt>std::nullptr&#95;t</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30302]&nbsp;&nbsp;In certain circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;use</span>&#95;frame&#95;pointer</tt></span> at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, the compiler could generate incorrect code for a tail call optimization that results in corruption of the frame pointer register. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30286]&nbsp;&nbsp;In certain circumstances, when compiling floating-point code with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=7&#45;M</tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;fpu</span>=FPv5&#95;D16</tt></span> at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, the compiler could generate a sequence of code in which a <span style="white-space:nowrap"><tt>VSEL</tt></span> instruction incorrectly appeared before the associated flag&#45;setting instruction. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30253]&nbsp;&nbsp;When compiling C&#43;&#43; code without <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;gnu</span></tt></span>, the <span style="white-space:nowrap"><tt>&#95;&#95;sync&#95;&#42;</tt></span> family of GNU built-in functions were incorrectly specified to return <b><span style="white-space:nowrap"><tt>void</tt></span></b> instead of the required <em>type</em>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30109]&nbsp;&nbsp;In certain circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span> at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could generate incorrect code when vectorizing expressions involving explicit type conversion from <b><span style="white-space:nowrap"><tt>unsigned</tt></span></b> <b><span style="white-space:nowrap"><tt>char</tt></span></b> and <b><span style="white-space:nowrap"><tt>short</tt></span></b> to <b><span style="white-space:nowrap"><tt>long</tt></span></b>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30027]&nbsp;&nbsp;Previously, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=7</tt></span>, the compiler would incorrectly allow function definitions to be qualified with the <span style="white-space:nowrap"><tt>&#95;&#95;irq</tt></span> keyword. This is invalid because interrupt handler entry and exit sequences are not common across Armv7&#45;A, Armv7&#45;R, and Armv7&#45;M. This has been fixed. The compiler now reports <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#3733:</tt></span> <span style="white-space:nowrap"><tt>&#95;&#95;irq</tt></span> <span style="white-space:nowrap"><tt>functions</tt></span> <span style="white-space:nowrap"><tt>cannot</tt></span> <span style="white-space:nowrap"><tt>be</tt></span> <span style="white-space:nowrap"><tt>generated</tt></span> <span style="white-space:nowrap"><tt>for</tt></span> <span style="white-space:nowrap"><tt>this</tt></span> <span style="white-space:nowrap"><tt>architecture</tt></span>. To compile <span style="white-space:nowrap"><tt>&#95;&#95;irq</tt></span> functions to have the correct entry and exit sequences, replace <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=7</tt></span> with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=<em>name</em></tt></span> where <em>name</em> is the name of a processor or architecture variant.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30013]&nbsp;&nbsp;In rare circumstances, when compiling for T32 state for a target that supports Thumb-2 technology, the compiler could generate incorrect code when a bitwise AND is involved in a conditional expression or in the controlling expression of a selection statement. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30010]&nbsp;&nbsp;In rare circumstances, when compiling for T32 state for a target that supports Thumb&#45;2 technology, at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could generate incorrect code for conditional expressions or statements. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30003]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, the compiler could generate an incorrect result when sign-extending an expression involving a variable whose address has previously been taken. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30002]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could incorrectly generate code that does not update the iteration variable of a <b><span style="white-space:nowrap"><tt>for</tt></span></b> loop that contains a <b><span style="white-space:nowrap"><tt>continue</tt></span></b> statement and is known at compile time to have one iteration. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30001]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate code that unconditionally executes statements contained in the body of a loop even though that loop may never be executed. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30000]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could incorrectly treat the result of an equality or relational operator as <b><span style="white-space:nowrap"><tt>unsigned</tt></span></b> <b><span style="white-space:nowrap"><tt>int</tt></span></b> instead of <b><span style="white-space:nowrap"><tt>int</tt></span></b>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29993]&nbsp;&nbsp;In certain circumstances, when compiling C&#43;&#43;11 code containing a <b><span style="white-space:nowrap"><tt>virtual</tt></span></b> method with a <b><span style="white-space:nowrap"><tt>noexcept</tt></span></b> specifier that overrides a method from a template base class, the compiler could incorrectly report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#766&#45;D:</tt></span> <span style="white-space:nowrap"><tt>exception</tt></span> <span style="white-space:nowrap"><tt>specification</tt></span> <span style="white-space:nowrap"><tt>for</tt></span> <span style="white-space:nowrap"><tt>virtual</tt></span> <span style="white-space:nowrap"><tt>&lt;entity&gt;</tt></span> <span style="white-space:nowrap"><tt>is</tt></span> <span style="white-space:nowrap"><tt>incompatible</tt></span> <span style="white-space:nowrap"><tt>with</tt></span> <span style="white-space:nowrap"><tt>that</tt></span> <span style="white-space:nowrap"><tt>of</tt></span> <span style="white-space:nowrap"><tt>overridden</tt></span> <span style="white-space:nowrap"><tt>&lt;entity&gt;</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29947]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, the compiler could generate incorrect code when an <b><span style="white-space:nowrap"><tt>unsigned</tt></span></b> <b><span style="white-space:nowrap"><tt>int</tt></span></b> is cast to a <b><span style="white-space:nowrap"><tt>double</tt></span></b> and that <b><span style="white-space:nowrap"><tt>double</tt></span></b> is then cast to a <b><span style="white-space:nowrap"><tt>long</tt></span></b> <b><span style="white-space:nowrap"><tt>long</tt></span></b>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29854]&nbsp;&nbsp;In certain circumstances, when compiling C&#43;&#43;11 code containing a constructor that is declared as a <b><span style="white-space:nowrap"><tt>constexpr</tt></span></b>, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x87ecef:&lt;ver&gt;]</tt></span> or a Windows <span style="white-space:nowrap"><tt>APPCRASH</tt></span> error. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29758]&nbsp;&nbsp;In rare circumstances, when compiling NEON intrinsics at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, or compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span> at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0xb36758:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29388]&nbsp;&nbsp;In certain circumstances, when compiling C&#43;&#43;11 code that contains a braced literal <b><span style="white-space:nowrap"><tt>struct</tt></span></b> initializer as an argument to a constructor, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x87ecef:&lt;ver&gt;]</tt></span> or a Windows <span style="white-space:nowrap"><tt>APPCRASH</tt></span> error. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29386]&nbsp;&nbsp;When compiling C&#43;&#43;11 code containing an <b><span style="white-space:nowrap"><tt>enum</tt></span></b> <b><span style="white-space:nowrap"><tt>class</tt></span></b> type with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;omf</span>&#95;browse</tt></span>, the compiler would report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x87ecef:&lt;ver&gt;]</tt></span> or a Windows <span style="white-space:nowrap"><tt>APPCRASH</tt></span> error. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29384]&nbsp;&nbsp;In certain circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;multifile</span></tt></span>, if the same variable is declared in multiple translation units and at least one of the declarations has an alignment attribute, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x87ecef:&lt;ver&gt;]</tt></span> or a Windows <span style="white-space:nowrap"><tt>APPCRASH</tt></span> error. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29003]&nbsp;&nbsp;In certain circumstances, when compiling C&#43;&#43;11 code containing a variadic template <span style="white-space:nowrap"><tt>T1</tt></span> that is used in an alias template definition <span style="white-space:nowrap"><tt>AT1</tt></span>, and <span style="white-space:nowrap"><tt>AT1</tt></span> is instantiated in another variadic template <span style="white-space:nowrap"><tt>T2</tt></span>, when <span style="white-space:nowrap"><tt>T2</tt></span> is instantiated the compiler could incorrectly report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#304:</tt></span> <span style="white-space:nowrap"><tt>no</tt></span> <span style="white-space:nowrap"><tt>instance</tt></span> <span style="white-space:nowrap"><tt>of</tt></span> <span style="white-space:nowrap"><tt>&lt;entity&gt;</tt></span> <span style="white-space:nowrap"><tt>matches</tt></span> <span style="white-space:nowrap"><tt>the</tt></span> <span style="white-space:nowrap"><tt>argument</tt></span> <span style="white-space:nowrap"><tt>list</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28973]&nbsp;&nbsp;In certain circumstances, when compiling C&#43;&#43;11 code containing variadic templates, the compiler could fail to properly substitute a variadic template argument when a given template has already been instantiated using similar expressions that should be considered distinct, and then incorrectly report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#871:</tt></span> <span style="white-space:nowrap"><tt>template</tt></span> <span style="white-space:nowrap"><tt>instantiation</tt></span> <span style="white-space:nowrap"><tt>resulted</tt></span> <span style="white-space:nowrap"><tt>in</tt></span> <span style="white-space:nowrap"><tt>unexpected</tt></span> <span style="white-space:nowrap"><tt>function</tt></span> <span style="white-space:nowrap"><tt>type</tt></span> <span style="white-space:nowrap"><tt>of</tt></span> <span style="white-space:nowrap"><tt>&lt;type&gt;</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-26533]&nbsp;&nbsp;In rare circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could incorrectly report <span style="white-space:nowrap"><tt>"no</tt></span> <span style="white-space:nowrap"><tt>source":</tt></span> <span style="white-space:nowrap"><tt>Warning:</tt></span> <span style="white-space:nowrap"><tt>#68&#45;D:</tt></span> <span style="white-space:nowrap"><tt>integer</tt></span> <span style="white-space:nowrap"><tt>conversion</tt></span> <span style="white-space:nowrap"><tt>resulted</tt></span> <span style="white-space:nowrap"><tt>in</tt></span> <span style="white-space:nowrap"><tt>a</tt></span> <span style="white-space:nowrap"><tt>change</tt></span> <span style="white-space:nowrap"><tt>of</tt></span> <span style="white-space:nowrap"><tt>sign</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-26059]&nbsp;&nbsp;In certain circumstances, when compiling source that contains an embedded assembler function on a Japanese Windows machine, and the username or <span style="white-space:nowrap"><tt>TMP</tt></span> environment variable contain non-ASCII characters, the compiler could incorrectly report <span style="white-space:nowrap"><tt>Fatal</tt></span> <span style="white-space:nowrap"><tt>error:</tt></span> <span style="white-space:nowrap"><tt>A1023E:</tt></span> <span style="white-space:nowrap"><tt>File</tt></span> <span style="white-space:nowrap"><tt>"&lt;filename&gt;"</tt></span> <span style="white-space:nowrap"><tt>could</tt></span> <span style="white-space:nowrap"><tt>not</tt></span> <span style="white-space:nowrap"><tt>be</tt></span> <span style="white-space:nowrap"><tt>opened:</tt></span> <span style="white-space:nowrap"><tt>No</tt></span> <span style="white-space:nowrap"><tt>such</tt></span> <span style="white-space:nowrap"><tt>file</tt></span> <span style="white-space:nowrap"><tt>or</tt></span> <span style="white-space:nowrap"><tt>directory</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-26058]&nbsp;&nbsp;In rare circumstances, when compiling source that contains an embedded assembler function on a Japanese Windows machine, the compiler could incorrectly report a Windows <span style="white-space:nowrap"><tt>BEX</tt></span> error. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25631]&nbsp;&nbsp;In certain circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span> at an inappropriate optimization level or for a target that does not support NEON, the compiler could incorrectly report <span style="white-space:nowrap"><tt>Warning:</tt></span> <span style="white-space:nowrap"><tt>C4361W:</tt></span> <span style="white-space:nowrap"><tt>Loop</tt></span> <span style="white-space:nowrap"><tt>optimizations</tt></span> <span style="white-space:nowrap"><tt>can</tt></span> <span style="white-space:nowrap"><tt>only</tt></span> <span style="white-space:nowrap"><tt>be</tt></span> <span style="white-space:nowrap"><tt>enabled</tt></span> <span style="white-space:nowrap"><tt>at</tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> <span style="white-space:nowrap"><tt>or</tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span> or fail to report a warning. This has been fixed. The compiler now reports either one or both of <span style="white-space:nowrap"><tt>Warning:</tt></span> <span style="white-space:nowrap"><tt>C4366W:</tt></span> <span style="white-space:nowrap"><tt>Vectorization</tt></span> <span style="white-space:nowrap"><tt>can</tt></span> <span style="white-space:nowrap"><tt>only</tt></span> <span style="white-space:nowrap"><tt>be</tt></span> <span style="white-space:nowrap"><tt>enabled</tt></span> <span style="white-space:nowrap"><tt>for</tt></span> <span style="white-space:nowrap"><tt>targets</tt></span> <span style="white-space:nowrap"><tt>with</tt></span> <span style="white-space:nowrap"><tt>NEON</tt></span> <span style="white-space:nowrap"><tt>capability</tt></span> and <span style="white-space:nowrap"><tt>Warning:</tt></span> <span style="white-space:nowrap"><tt>C4367W:</tt></span> <span style="white-space:nowrap"><tt>Vectorization</tt></span> <span style="white-space:nowrap"><tt>can</tt></span> <span style="white-space:nowrap"><tt>only</tt></span> <span style="white-space:nowrap"><tt>be</tt></span> <span style="white-space:nowrap"><tt>enabled</tt></span> <span style="white-space:nowrap"><tt>at</tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> <span style="white-space:nowrap"><tt>or</tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span>.</p>
    </li>
    
    <li>
    <p>[SDCOMP-23625]&nbsp;&nbsp;In rare circumstances, when compiling an inline assembler instruction involving a shift other than <span style="white-space:nowrap"><tt>RRX</tt></span>, the compiler could incorrectly report <span style="white-space:nowrap"><tt>Warning:</tt></span> <span style="white-space:nowrap"><tt>C4007E:</tt></span> <span style="white-space:nowrap"><tt>Uninitialised</tt></span> <span style="white-space:nowrap"><tt>or</tt></span> <span style="white-space:nowrap"><tt>corrupted</tt></span> <span style="white-space:nowrap"><tt>use</tt></span> <span style="white-space:nowrap"><tt>of</tt></span> <span style="white-space:nowrap"><tt>PSR.</tt></span> <span style="white-space:nowrap"><tt>This</tt></span> <span style="white-space:nowrap"><tt>code</tt></span> <span style="white-space:nowrap"><tt>may</tt></span> <span style="white-space:nowrap"><tt>not</tt></span> <span style="white-space:nowrap"><tt>work</tt></span> <span style="white-space:nowrap"><tt>correctly</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-15500]&nbsp;&nbsp;In certain circumstances, when an expression addressing an unsigned bitfield appears on the right-hand side of a comma operator and the other operand is of signed integer type, the compiler could incorrectly promote the result of the operator to unsigned type. This has been fixed.</p>
    </li>
    

</ul>

<h5>Assembler (armasm)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-25912]&nbsp;&nbsp;When assembling <span style="white-space:nowrap"><tt>MRS</tt></span> or <span style="white-space:nowrap"><tt>MSR</tt></span> instructions that access the system registers <span style="white-space:nowrap"><tt>PAR</tt></span>, <span style="white-space:nowrap"><tt>TTBR0</tt></span>, or <span style="white-space:nowrap"><tt>TTBR1</tt></span> for a target that implements the Large Physical Address Extension (LPAE), the assembler would incorrectly report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>A1902E:</tt></span> <span style="white-space:nowrap"><tt>Specified</tt></span> <span style="white-space:nowrap"><tt>special</tt></span> <span style="white-space:nowrap"><tt>register</tt></span> <span style="white-space:nowrap"><tt>not</tt></span> <span style="white-space:nowrap"><tt>supported</tt></span> <span style="white-space:nowrap"><tt>on</tt></span> <span style="white-space:nowrap"><tt>target</tt></span> <span style="white-space:nowrap"><tt>architecture</tt></span>. This has been fixed.</p>
    </li>
    

</ul>

<h5>Linker (armlink)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-24039]&nbsp;&nbsp;In certain circumstances, the linker could report incorrect load addresses in messages of the form <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>L6788E:</tt></span> <span style="white-space:nowrap"><tt>Scatter&#45;loading</tt></span> <span style="white-space:nowrap"><tt>of</tt></span> <span style="white-space:nowrap"><tt>execution</tt></span> <span style="white-space:nowrap"><tt>region</tt></span> <span style="white-space:nowrap"><tt>&lt;er1name&gt;</tt></span> <span style="white-space:nowrap"><tt>to</tt></span> <span style="white-space:nowrap"><tt>[&lt;base1&gt;,&lt;limit1&gt;)</tt></span> <span style="white-space:nowrap"><tt>will</tt></span> <span style="white-space:nowrap"><tt>cause</tt></span> <span style="white-space:nowrap"><tt>the</tt></span> <span style="white-space:nowrap"><tt>contents</tt></span> <span style="white-space:nowrap"><tt>of</tt></span> <span style="white-space:nowrap"><tt>execution</tt></span> <span style="white-space:nowrap"><tt>region</tt></span> <span style="white-space:nowrap"><tt>&lt;er2name&gt;</tt></span> <span style="white-space:nowrap"><tt>at</tt></span> <span style="white-space:nowrap"><tt>[&lt;base2&gt;,&lt;limit2&gt;)</tt></span> <span style="white-space:nowrap"><tt>to</tt></span> <span style="white-space:nowrap"><tt>be</tt></span> <span style="white-space:nowrap"><tt>corrupted</tt></span> <span style="white-space:nowrap"><tt>at</tt></span> <span style="white-space:nowrap"><tt>run&#45;time</tt></span>. This has been fixed.</p>
    </li>
    

</ul>

<h5>Libraries</h5>
<ul>

    
    <li>
    <p>[SDCOMP-30835]&nbsp;&nbsp;The standard header <span style="white-space:nowrap"><tt>stdint.h</tt></span> incorrectly defined the standard C macro <span style="white-space:nowrap"><tt>UINTPTR&#95;MAX</tt></span> as <span style="white-space:nowrap"><tt>&#40;2&#94;31&#41;&#45;1</tt></span> instead of <span style="white-space:nowrap"><tt>&#40;2&#94;32&#41;&#45;1</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-30831]&nbsp;&nbsp;The standard C library implementations of the <span style="white-space:nowrap"><tt>printf&#40;&#41;</tt></span> family of functions, when formatting a floating&#45;point number in hexadecimal format using <span style="white-space:nowrap"><tt>%a</tt></span> or <span style="white-space:nowrap"><tt>%A</tt></span>, would incorrectly omit the hexadecimal&#45;point character from the formatted output when the <span style="white-space:nowrap"><tt>#</tt></span> flag is specified and the value after the hexadecimal point is zero. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29760]&nbsp;&nbsp;The standard C library implementations of the <span style="white-space:nowrap"><tt>strtod&#40;&#41;</tt></span> and <span style="white-space:nowrap"><tt>scanf&#40;&#41;</tt></span> families of functions would return incorrect results when parsing a string in C99 hexadecimal floating-point syntax, when all the digits before the hexadecimal point and at least one digit following the hexadecimal point are zero, for example <span style="white-space:nowrap"><tt>"0x0.00E"</tt></span>. This has been fixed.</p>
    </li>
    

</ul>






<h3>Changes in Arm Compiler 5.06 update 1</h3>




<h4>General changes in Arm Compiler 5.06 update 1</h4>


<ul>

    
    <li>
    <p>[SDCOMP-29957]&nbsp;&nbsp;The <span style="white-space:nowrap"><tt>&#95;&#95;sync&#95;&#42;</tt></span> family of GNU built-in functions were previously only available when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;gnu</span></tt></span>. These functions are now available in all source language modes.</p>
    </li>
    

</ul>



<h4>Defect fixes in Arm Compiler 5.06 update 1</h4>



<h5>Compiler (armcc)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-29910]&nbsp;&nbsp;When compiling for any processor except for Cortex-M processors, Arm Compiler 5.06 (build 20) would generate incorrect code for functions that are qualified with the <span style="white-space:nowrap"><tt>&#95;&#95;irq</tt></span> keyword. The generated code preserved only the registers that are required to be preserved by the AAPCS rather than preserving all processor registers. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29862]&nbsp;&nbsp;In certain circumstances, the compiler could incorrectly generate code that fails to load the top half of a 64&#45;bit <b><span style="white-space:nowrap"><tt>volatile</tt></span></b> value when only the bottom 32 bits are used by subsequent code. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29767]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code when C99 designated initializers are used. This has been fixed. </p>
    </li>
    
    <li>
    <p>[SDCOMP-29633]&nbsp;&nbsp;When compiling C&#43;&#43; code containing a <b><span style="white-space:nowrap"><tt>static</tt></span></b> variable that is declared with &#95;&#95;attribute&#95;&#95;&#40;&#40;section&#40;"name"&#41;&#41;&#41; in an inline function or an inline class member function, the compiler would incorrectly ignore the attribute. In certain circumstances, the compiler could also report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x58a8aa:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29585]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code when processing a nested loop where loop counters are used as part of an assignment statement within the innermost loop. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29544]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could incorrectly assume that the values of elements in a multi-dimensional array would not change from their initial values. This could result in the compiler generating incorrect code. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29543]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could incorrectly fail to sign extend the return value for a function that returns a signed integer when the expression receiving the returned value is of a wider integer type. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29542]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could incorrectly treat the result of an equality operator or a relational operator as <b><span style="white-space:nowrap"><tt>unsigned</tt></span></b> <b><span style="white-space:nowrap"><tt>int</tt></span></b> instead of <b><span style="white-space:nowrap"><tt>int</tt></span></b>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29487]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for loops that increment pointers and perform memory accesses. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29464]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, the compiler could generate a sequence of code that incorrectly used a flag-setting instruction, corrupting the flags required by a subsequent flag-reading instruction. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29431]&nbsp;&nbsp;In certain circumstances, the compiler could ignore a <span style="white-space:nowrap"><tt>&#35;pragma</tt></span> <span style="white-space:nowrap"><tt>arm</tt></span> <span style="white-space:nowrap"><tt>section</tt></span> directive related to read-only data for initialization constants when partially initializing a <b><span style="white-space:nowrap"><tt>struct</tt></span></b>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29383]&nbsp;&nbsp;In certain circumstances, when compiling C&#43;&#43;11 code containing braced initialization lists for class members, with exceptions disabled, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x87ecef:&lt;ver&gt;]</tt></span> or a Windows <span style="white-space:nowrap"><tt>APPCRASH</tt></span> error. This has been fixed.</p>
    </li>
    

</ul>

<h5>Libraries</h5>
<ul>

    
    <li>
    <p>[SDCOMP-29102]&nbsp;&nbsp;The standard C library implementation of the <span style="white-space:nowrap"><tt>strftime&#40;&#41;</tt></span> function would generate incorrect results when using the <span style="white-space:nowrap"><tt>&#37;C</tt></span> or <span style="white-space:nowrap"><tt>&#37;h</tt></span> format specifiers. This has been fixed.</p>
    </li>
    

</ul>

<h5>Other issues</h5>
<ul>

    
    <li>
    <p>[SDCOMP-29337]&nbsp;&nbsp;In certain circumstances, the compiler could incorrectly report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>C9558E:</tt></span> <span style="white-space:nowrap"><tt>System</tt></span> <span style="white-space:nowrap"><tt>clock</tt></span> <span style="white-space:nowrap"><tt>tampering</tt></span> <span style="white-space:nowrap"><tt>detected.</tt></span> <span style="white-space:nowrap"><tt>License</tt></span> <span style="white-space:nowrap"><tt>checkout</tt></span> <span style="white-space:nowrap"><tt>will</tt></span> <span style="white-space:nowrap"><tt>fail</tt></span> when files with very old timestamps are present in the file system. This has been fixed.</p>
    </li>
    

</ul>






<h3>Changes in Arm Compiler 5.06</h3>


<p>
Changes are listed since the previous feature release,
Arm Compiler 5.05.
</p>



<h4>General changes in Arm Compiler 5.06</h4>


<ul>

    
    <li>
    <p>[SDCOMP-22253]&nbsp;&nbsp;The following changes have been made to supported host platforms:</p>
<ul>
    <li>Support for Windows 8 moves to Windows 8.1, 64&#45;bit only.</li>
    <li>Support has been deprecated for Windows XP Professional SP3.</li>
    <li>Support has been deprecated for Windows Server 2008 R2.</li>
    <li>Support has been deprecated for Ubuntu Desktop Edition 12.04 LTS.</li>
    <li>Support has been deprecated for Red Hat Enterprise Linux 5 Desktop with Workstation option.</li>
</ul>


<p>From Arm Compiler 5.06 update 2, the deprecated host platforms are no longer supported.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29393]&nbsp;&nbsp;Previously the installer did not support coexisting installations of different Arm Compiler 5 releases. Any existing installation was automatically removed or upgraded irrespective of the destination folder. This behavior has been changed. The installer will no longer automatically remove or upgrade an existing installation:</p>
<ul>
    <li>To create a coexisting installation, select a destination folder that does not contain an existing installation.</li>
    <li>To replace or upgrade an existing installation, uninstall the existing version before installing the replacement.</li>
</ul><p></p>
    </li>
    
    <li>
    <p>[SDCOMP-24529]&nbsp;&nbsp;Support for the following processors has been deprecated in Arm Compiler 5.06:</p>
<ul>
    <li>88FR101.</li>
    <li>88FR101.hw&#95;divide.</li>
    <li>88FR111.</li>
    <li>88FR111.no&#95;hw&#95;divide.</li>
    <li>88FR121.</li>
    <li>88FR121.hw&#95;divide.</li>
    <li>88FR131.</li>
    <li>88FR131.hw&#95;divide.</li>
    <li>88FR301.</li>
    <li>88FR301.hw&#95;divide.</li>
    <li>88FR321.</li>
    <li>88FR321.hw&#95;divide.</li>
    <li>88FR331.</li>
    <li>88FR331.hw&#95;divide.</li>
    <li>Arm710T.</li>
    <li>Arm740T.</li>
    <li>Arm7TDM.</li>
    <li>Arm7TM.</li>
    <li>Arm7TM&#45;S.</li>
    <li>Arm810.</li>
    <li>Arm940T.</li>
    <li>Arm968E&#45;S.</li>
    <li>Arm9EJ&#45;S.</li>
    <li>Arm1022E.</li>
    <li>Arm1026EJ&#45;S.</li>
    <li>Arm1156T2F&#45;S.</li>
    <li>SA&#45;110.</li>
    <li>SA&#45;1100.</li>
</ul>


<p>Replace affected <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=<em>name</em></tt></span> options as follows:</p>
<ul>
    <li>Use <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=4</tt></span> instead of <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM810</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=SA&#45;110</tt></span>, or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=SA&#45;1100</tt></span>.</li>
    <li>Use <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM7TDMI</tt></span> instead of <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM710T</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM740T</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM7TDM</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM7TM</tt></span>, or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM7TM&#45;S</tt></span>.</li>
    <li>Use <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM9TDMI</tt></span> instead of <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM940T</tt></span>.</li>
    <li>Use <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=5TE</tt></span> instead of <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR101</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR101.hw&#95;divide</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR111</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR111.no&#95;hw&#95;divide</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR121</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR121.hw&#95;divide</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR131</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR131.hw&#95;divide</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR301</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR301.hw&#95;divide</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR321</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR321.hw&#95;divide</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR331</tt></span>, <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=88FR331.hw&#95;divide</tt></span>, or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM968E&#45;S</tt></span>.</li>
    <li>Use <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=5TEJ</tt></span> instead of <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM9EJ&#45;S</tt></span>.</li>
    <li>Use <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM1020E</tt></span> instead of <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM1022E</tt></span> or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM1026EJ&#45;S</tt></span>.</li>
    <li>Use <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM1156T2&#45;S</tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;fpu</span>=VFPv2</tt></span> instead of <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=ARM1156T2F&#45;S</tt></span>.</li>
</ul>


<p>From Arm Compiler 5.06 update 3, support for the deprecated processors has been removed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-13769]&nbsp;&nbsp;The compiler now fully supports the following memory barrier instruction intrinsics:</p>
<ul>
    <li><span style="white-space:nowrap"><tt>&#95;&#95;isb&#40;&#41;</tt></span></li>
    <li><span style="white-space:nowrap"><tt>&#95;&#95;dsb&#40;&#41;</tt></span></li>
    <li><span style="white-space:nowrap"><tt>&#95;&#95;dmb&#40;&#41;</tt></span></li>
</ul>


<p>Support has also been added for an additional optimization barrier intrinsic:</p>
<ul>
    <li><span style="white-space:nowrap"><tt>&#95;&#95;force&#95;loads&#40;&#41;</tt></span></li>
</ul>


<p>These intrinsics are described in the <em>armcc User Guide</em>.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25014]&nbsp;&nbsp;The behavior of <span style="white-space:nowrap"><tt>&#95;&#95;declspec&#40;noreturn&#41;</tt></span> and <span style="white-space:nowrap"><tt>&#95;&#95;attribute&#95;&#95;&#40;&#40;noreturn&#41;&#41;</tt></span> has changed. If a function decorated with either extension implicitly or explicitly returns, the compiler now ignores the <span style="white-space:nowrap"><tt>&#95;&#95;attribute&#95;&#95;&#40;&#40;noreturn&#41;&#41;</tt></span> or <span style="white-space:nowrap"><tt>&#95;&#95;declspec&#40;noreturn&#41;</tt></span> and reports <span style="white-space:nowrap"><tt>Warning:</tt></span> <span style="white-space:nowrap"><tt>#1461&#45;D:</tt></span> <span style="white-space:nowrap"><tt>function</tt></span> <span style="white-space:nowrap"><tt>declared</tt></span> <span style="white-space:nowrap"><tt>with</tt></span> <span style="white-space:nowrap"><tt>"noreturn"</tt></span> <span style="white-space:nowrap"><tt>does</tt></span> <span style="white-space:nowrap"><tt>return</tt></span>. This warning can be optionally downgraded or suppressed. The <em>armcc User Guide</em> provides more information about these extensions.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29571]&nbsp;&nbsp;In certain circumstances, when compiling functions that are declared as deleted using the C&#43;&#43;11 keyword <b><span style="white-space:nowrap"><tt>delete</tt></span></b>, the compiler could report <span style="white-space:nowrap"><tt>Warning</tt></span> <span style="white-space:nowrap"><tt>#177&#45;D:</tt></span> <span style="white-space:nowrap"><tt>&lt;entity&gt;</tt></span> <span style="white-space:nowrap"><tt>was</tt></span> <span style="white-space:nowrap"><tt>declared</tt></span> <span style="white-space:nowrap"><tt>but</tt></span> <span style="white-space:nowrap"><tt>never</tt></span> <span style="white-space:nowrap"><tt>referenced</tt></span>. This behavior has been changed. The warning is no longer reported in these cases.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25883]&nbsp;&nbsp;In Arm Compiler 5.05, the behavior in <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;gnu</span></tt></span> mode was changed to not allow an lvalue reference to a <b><span style="white-space:nowrap"><tt>const</tt></span></b> <b><span style="white-space:nowrap"><tt>volatile</tt></span></b> argument type to be accepted as a match for an rvalue reference in overload resolution. This is strictly compliant with the C&#43;&#43; standard. In certain circumstances, this causes Arm Compiler 5.05 to report errors for C&#43;&#43; source that can be successfully compiled by previous releases of Arm Compiler. The behavior prior to Arm Compiler 5.05 has been restored for <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;gnu</span></tt></span> mode only.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25881]&nbsp;&nbsp;In Arm Compiler 5.05, the behavior in <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;gnu</span></tt></span> mode was changed to always check that a copy constructor was callable and could be successfully instantiated even if it was being optimized out at a particular call. This is strictly compliant with the C&#43;&#43; standard. In certain circumstances, for example when a copy constructor that uses incomplete types is instantiated without the full type declarations being available, this causes Arm Compiler 5.05 to report errors for C&#43;&#43; source that can be successfully compiled by previous releases of Arm Compiler. The behavior prior to Arm Compiler 5.05 has been restored for <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;gnu</span></tt></span> mode only.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29787]&nbsp;&nbsp;The compiler previously ignored <span style="white-space:nowrap"><tt>#pragma</tt></span> <span style="white-space:nowrap"><tt>arm</tt></span> <span style="white-space:nowrap"><tt>section</tt></span> <span style="white-space:nowrap"><tt>&#91;<em>section&#95;type&#95;list</em>&#93;</tt></span> for out-of-line copies of inline functions. This behavior has been changed. The pragma now also affects out-of-line copies of inline functions. To restore the previous behavior, use the following option:</p>
<ul>
    <li><span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;no</span>&#95;ool&#95;section&#95;name</tt></span></li>
</ul><p></p>
    </li>
    
    <li>
    <p>[SDCOMP-29788]&nbsp;&nbsp;When linking using <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;partial</span></tt></span>, the linker previously generated an <span style="white-space:nowrap"><tt>SHT&#95;ARM&#95;ATTRIBUTES</tt></span> section containing file-scope build attributes set to <span style="white-space:nowrap"><tt>Tag&#95;nodefaults</tt></span>. All build attribute tags were described in each individual <span style="white-space:nowrap"><tt>SHF&#95;ALLOC</tt></span> section. This behavior has been changed. The linker now generates file-scope build attributes that describe the most restrictive compatibility requirements of the <span style="white-space:nowrap"><tt>SHF&#95;ALLOC</tt></span> sections. This change in behavior increases compatibility with other toolchains. Both the previous and new behavior conform to the <em>Application Binary Interface for the Arm Architecture</em>.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29592]&nbsp;&nbsp;The default <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;gnu</span>&#95;version</tt></span> has been changed from <span style="white-space:nowrap"><tt>40200</tt></span> to <span style="white-space:nowrap"><tt>40700</tt></span>. Unless a different <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;gnu</span>&#95;version=<em>version</em></tt></span> is specified, the compiler now emulates the behavior of GCC version 4.7.0 as closely as possible when the <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;gnu</span></tt></span> option is used.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28484]&nbsp;&nbsp;The control of license management warnings has been improved:</p>
<ul>
    <li>The <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;diag</span>&#95;remark</tt></span> and <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;diag</span>&#95;suppress</tt></span> options can now be used to downgrade or suppress all license management warnings.</li>
    <li>The <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;diag</span>&#95;error=warning</tt></span> option now upgrades all warnings except for license management warnings to error severity.</li>
</ul><p></p>
    </li>
    
    <li>
    <p>[SDCOMP-17855]&nbsp;&nbsp;The <span style="white-space:nowrap"><tt>&#95;&#95;ldrex</tt></span> and <span style="white-space:nowrap"><tt>&#95;&#95;strex</tt></span> family of intrinsics have been deprecated, and use of the <span style="white-space:nowrap"><tt>LDREX</tt></span> and <span style="white-space:nowrap"><tt>STREX</tt></span> family of instructions in inline assembly code has also been deprecated. Use one of the following alternatives:</p>
<ul>
    <li>Write code that uses these instructions in an embedded assembler function.</li>
    <li>Use an appropriate member of the <span style="white-space:nowrap"><tt>&#95;&#95;sync&#95;*</tt></span> family of GNU built-in functions, for example <span style="white-space:nowrap"><tt>&#95;&#95;sync&#95;lock&#95;test&#95;and&#95;set&#40;&#41;</tt></span>.</li>
</ul><p></p>
    </li>
    
    <li>
    <p>[SDCOMP-28842]&nbsp;&nbsp;The <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;fpu</span></tt></span> option has been extended to support the FPv5 architecture:</p>
<ul>
    <li><span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;fpu</span>=FPv5&#95;D16</tt></span> selects a hardware floating-point unit conforming to the FPv5&#45;D16 architecture.</li>
    <li><span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;fpu</span>=FPv5&#45;SP</tt></span> selects a hardware floating-point unit conforming to the single-precision variant of the FPv5 architecture.</li>
    <li><span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;fpu</span>=SoftVFP+FPv5&#95;D16</tt></span> selects a hardware floating-point unit conforming to FPv5&#45;D16, with software floating&#45;point linkage.</li>
    <li><span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;fpu</span>=SoftVFP+FPv5&#45;SP</tt></span> selects a hardware floating-point unit conforming to FPv5&#45;SP, with software floating&#45;point linkage.</li>
</ul><p></p>
    </li>
    
    <li>
    <p>[SDCOMP-30343]&nbsp;&nbsp;Support has been added for a workaround for the Arm Cortex&#45;M3 erratum 838469. To enable the workaround, use the following compiler option:</p>
<ul>
    <li><span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;branchpatch</span>=cortex&#45;m3&#45;838469</tt></span></li>
</ul><p></p>
    </li>
    
    <li>
    <p>[SDCOMP-30400]&nbsp;&nbsp;Support has been added for a workaround for the Arm Cortex&#45;M4 erratum 838869. To enable the workaround, use the following compiler option:</p>
<ul>
    <li><span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;branchpatch</span>=cortex&#45;m4&#45;838869</tt></span></li>
</ul><p></p>
    </li>
    

</ul>



<h4>Defect fixes in Arm Compiler 5.06</h4>



<h5>Compiler (armcc)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-29640]&nbsp;&nbsp;In certain circumstances, when compiling for a hardware floating-point unit conforming to the single-precision variant of the FPv5 architecture, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0xd82ad8:&lt;ver&gt;]</tt></span> when processing an expression that uses the conditional operator <span style="white-space:nowrap"><tt>?</tt></span> <span style="white-space:nowrap"><tt>:</tt></span> with a floating-point value or variable. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29304]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could generate incorrect code when the result of an arithmetic expression containing a bitwise Exclusive OR and a bitwise OR operator is assigned to a variable of integer type that is smaller than a 32&#45;bit integer. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29280]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, the compiler could generate incorrect code when a location in memory is written to without using <b><span style="white-space:nowrap"><tt>volatile</tt></span></b> followed by another write to the same location that does use <b><span style="white-space:nowrap"><tt>volatile</tt></span></b>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29267]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could incorrectly optimize an expression involving two operators that are either:</p>
<ul>
    <li>Both bitwise OR.</li>
    <li>Both bitwise Exclusive OR.</li>
    <li>A combination of bitwise OR and bitwise Exclusive OR.</li>
</ul>


<p>This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29261]&nbsp;&nbsp;In rare circumstances, when compiling for T32 state, the compiler could generate incorrect code for a program that reads from a number of contiguous memory locations where it can be determined that some of the reads can be eliminated. This could result in a failure to load some of the required data. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29257]&nbsp;&nbsp;In certain circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;debug</span></tt></span> or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;g</span></tt></span>, the compiler could produce incomplete debug information for data that is allocated to registers rather than memory. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29252]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could incorrectly allocate variables local to a block of code to the same memory locations as variables outside of the block of code. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29222]&nbsp;&nbsp;In rare circumstances, when compiling for A32 state, the compiler could generate incorrect code for calculating addresses for loads and stores. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29191]&nbsp;&nbsp;In rare circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span> at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could generate incorrect code when vectorizing a loop that writes to an array. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29189]&nbsp;&nbsp;In rare circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span> at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could generate incorrect code for a loop that casts the elements of an array of integer type to <b><span style="white-space:nowrap"><tt>float</tt></span></b> to perform a floating&#45;point calculation, and the result is cast back to an integer type for further calculations. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29160]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a <b><span style="white-space:nowrap"><tt>for</tt></span></b> loop that modifies a pointer which aliases the loop index. This could result in an incorrect number of iterations of the loop. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29158]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a program containing nested <b><span style="white-space:nowrap"><tt>for</tt></span></b> loops, resulting in an inner loop body incorrectly being executed. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29157]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for expressions of the form <span style="white-space:nowrap"><tt>A</tt></span> <span style="white-space:nowrap"><tt>&amp;</tt></span> <span style="white-space:nowrap"><tt>B</tt></span> when one of <span style="white-space:nowrap"><tt>A</tt></span> or <span style="white-space:nowrap"><tt>B</tt></span> can be evaluated at compile time to zero and the other expression contains an increment or decrement operator. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29155]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code when a parameter of a function is always passed the same value, and the value is not in range of the type of the parameter. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29151]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a control statement having a controlling expression of the form <span style="white-space:nowrap"><tt>A</tt></span> <span style="white-space:nowrap"><tt>&lt;=</tt></span> <span style="white-space:nowrap"><tt>B</tt></span> or <span style="white-space:nowrap"><tt>A</tt></span> <span style="white-space:nowrap"><tt>&gt;</tt></span> <span style="white-space:nowrap"><tt>B</tt></span>, where expression <span style="white-space:nowrap"><tt>A</tt></span> can be evaluated at compile time to zero and <span style="white-space:nowrap"><tt>B</tt></span> is of an unsigned type. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29117]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could generate code containing execution paths that do not have correctly balanced <span style="white-space:nowrap"><tt>PUSH</tt></span> and <span style="white-space:nowrap"><tt>POP</tt></span> instructions. This could corrupt the stack, resulting in incorrect behavior. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29030]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for expressions of the form <span style="white-space:nowrap"><tt>A</tt></span> <span style="white-space:nowrap"><tt><em>relational-operator</em></tt></span> <span style="white-space:nowrap"><tt>B</tt></span> when both <span style="white-space:nowrap"><tt>A</tt></span> and <span style="white-space:nowrap"><tt>B</tt></span> are of integer type and have known values at compile time. This has been fixed. </p>
    </li>
    
    <li>
    <p>[SDCOMP-29029]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a <b><span style="white-space:nowrap"><tt>for</tt></span></b> loop that has an iteration variable, <span style="white-space:nowrap"><tt>X</tt></span>, where <span style="white-space:nowrap"><tt>X</tt></span> is of signed integer type, has an initial value that is not known at compile time, and that may overflow or underflow the range of values for its type. This could result in the loop body not being entered for all the expected initial values of <span style="white-space:nowrap"><tt>X</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29028]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could incorrectly fail to generate code for an <b><span style="white-space:nowrap"><tt>if</tt></span></b> statement where the value of the controlling expression, except for any side&#45;effects, can be evaluated at compile time. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29026]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a <b><span style="white-space:nowrap"><tt>for</tt></span></b> loop that has an iteration variable, <span style="white-space:nowrap"><tt>X</tt></span>, that must overflow or underflow in order to reach the loop termination condition, and <span style="white-space:nowrap"><tt>X</tt></span> is of signed <b><span style="white-space:nowrap"><tt>char</tt></span></b> or signed <b><span style="white-space:nowrap"><tt>short</tt></span></b> type. This could result in a failure to enter the loop body. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-29025]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for accesses to members of structures declared under <span style="white-space:nowrap"><tt>#pragma</tt></span> <span style="white-space:nowrap"><tt>pack&#40;4&#41;</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28950]&nbsp;&nbsp;In rare circumstances, when compiling for T32 state at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could generate a sequence of code that incorrectly contains a flag-setting <span style="white-space:nowrap"><tt>MULS</tt></span> instruction rather than the non&#45;flag&#45;setting <span style="white-space:nowrap"><tt>MUL</tt></span> instruction. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28790]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could incorrectly pass only the first character when a string literal is used as the argument for a C&#43;&#43; function parameter that is a reference to an array of characters. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28788]&nbsp;&nbsp;In rare circumstances, when inlining a function into the <span style="white-space:nowrap"><tt>main&#40;&#41;</tt></span> function at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could incorrectly remove a write to a global variable by the function being inlined. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28753]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code when unrolling a loop. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28700]&nbsp;&nbsp;When compiling code that contains lvalue casts with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;gnu</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;gnu</span>&#95;version=30400</tt></span>, the compiler would report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x87ecef:&lt;ver&gt;]</tt></span> or a Windows <span style="white-space:nowrap"><tt>APPCRASH</tt></span> error. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28669]&nbsp;&nbsp;In rare circumstances, when compiling conditional expressions for A32 state at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0xe4ffdb:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28666]&nbsp;&nbsp;When compiling C&#43;&#43;11 code containing an expression of the form <span style="white-space:nowrap"><tt>&#40;void&#41;v</tt></span> or <span style="white-space:nowrap"><tt>static&#95;cast&lt;void&gt;&#40;v&#41;</tt></span> where <span style="white-space:nowrap"><tt>v</tt></span> is a <b><span style="white-space:nowrap"><tt>volatile</tt></span></b> variable, the compiler would incorrectly fail to generate a read from <span style="white-space:nowrap"><tt>v</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28651]&nbsp;&nbsp;In certain circumstances, the compiler could generate incorrect code for a chained <b><span style="white-space:nowrap"><tt>struct</tt></span></b> or <b><span style="white-space:nowrap"><tt>class</tt></span></b> assignment <span style="white-space:nowrap"><tt>x</tt></span> <span style="white-space:nowrap"><tt>=</tt></span> <span style="white-space:nowrap"><tt>y</tt></span> <span style="white-space:nowrap"><tt>=</tt></span> <span style="white-space:nowrap"><tt>z</tt></span>, resulting in the rvalue expression <span style="white-space:nowrap"><tt>z</tt></span> being evaluated more than once. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28552]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could generate incorrect code for assignment expressions involving nested conditionals when the assigned value is never used. The assignment could be written to the wrong variable, resulting in incorrect behavior. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28423]&nbsp;&nbsp;When compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpp11</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;g</span></tt></span> or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpp11</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;debug</span></tt></span>, use of the type <b><span style="white-space:nowrap"><tt>std::nullptr&#95;t</tt></span></b> would cause the compiler to report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x6983ab:&lt;ver&gt;]</tt></span>, <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0xd1dee6:&lt;ver&gt;]</tt></span>, or <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0xe66931:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28421]&nbsp;&nbsp;When compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpp11</span></tt></span>, an expression involving an assignment to an rvalue reference of type <span style="white-space:nowrap"><tt>std::nullptr&#95;t</tt></span> would cause the compiler to report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x44784c:&lt;ver&gt;]</tt></span>. This has been fixed. </p>
    </li>
    
    <li>
    <p>[SDCOMP-28420]&nbsp;&nbsp;In certain circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpp11</span></tt></span>, the compiler could incorrectly ignore a <b><span style="white-space:nowrap"><tt>constexpr</tt></span></b> specifier resulting in one or more reports of <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#28:</tt></span> <span style="white-space:nowrap"><tt>expression</tt></span> <span style="white-space:nowrap"><tt>must</tt></span> <span style="white-space:nowrap"><tt>have</tt></span> <span style="white-space:nowrap"><tt>a</tt></span> <span style="white-space:nowrap"><tt>constant</tt></span> <span style="white-space:nowrap"><tt>value</tt></span> or <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#3673:</tt></span> <span style="white-space:nowrap"><tt>function</tt></span> <span style="white-space:nowrap"><tt>call</tt></span> <span style="white-space:nowrap"><tt>must</tt></span> <span style="white-space:nowrap"><tt>have</tt></span> <span style="white-space:nowrap"><tt>a</tt></span> <span style="white-space:nowrap"><tt>constant</tt></span> <span style="white-space:nowrap"><tt>value</tt></span> <span style="white-space:nowrap"><tt>in</tt></span> <span style="white-space:nowrap"><tt>a</tt></span> <span style="white-space:nowrap"><tt>constant</tt></span> <span style="white-space:nowrap"><tt>expression</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28391]&nbsp;&nbsp;When compiling a <b><span style="white-space:nowrap"><tt>virtual</tt></span></b> destructor that has an exception specification with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpp11</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;exceptions</span></tt></span>, the compiler would incorrectly report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#766&#45;D:</tt></span> <span style="white-space:nowrap"><tt>exception</tt></span> <span style="white-space:nowrap"><tt>specification</tt></span> <span style="white-space:nowrap"><tt>for</tt></span> <span style="white-space:nowrap"><tt>virtual</tt></span> <span style="white-space:nowrap"><tt>&lt;entity&gt;</tt></span> <span style="white-space:nowrap"><tt>is</tt></span> <span style="white-space:nowrap"><tt>incompatible</tt></span> <span style="white-space:nowrap"><tt>with</tt></span> <span style="white-space:nowrap"><tt>that</tt></span> <span style="white-space:nowrap"><tt>of</tt></span> <span style="white-space:nowrap"><tt>overridden</tt></span> <span style="white-space:nowrap"><tt>&lt;entity&gt;</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28328]&nbsp;&nbsp;When compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpp11</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;omf</span>&#95;browse=<em>filename</em>.crf</tt></span>, a scoped enumeration declared with <b><span style="white-space:nowrap"><tt>enum</tt></span></b> <b><span style="white-space:nowrap"><tt>class</tt></span></b> or <b><span style="white-space:nowrap"><tt>enum</tt></span></b> <b><span style="white-space:nowrap"><tt>struct</tt></span></b> would cause the compiler to report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x87ecef:&lt;ver&gt;]</tt></span> or a Windows <span style="white-space:nowrap"><tt>APPCRASH</tt></span> error. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28288]&nbsp;&nbsp;In certain circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpp11</span></tt></span> at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span>, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x6bca8b:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28272]&nbsp;&nbsp;In certain circumstances, when preprocessing a source file that uses a multibyte encoding in which ordinary ASCII characters can appear as consecutive bytes of a multibyte character, the compiler could incorrectly expand macros containing the <b><span style="white-space:nowrap"><tt>#</tt></span></b> operator. This could result in error messages such as <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#8:</tt></span> <span style="white-space:nowrap"><tt>missing</tt></span> <span style="white-space:nowrap"><tt>closing</tt></span> <span style="white-space:nowrap"><tt>quote</tt></span> or <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#54&#45;D:</tt></span> <span style="white-space:nowrap"><tt>too</tt></span> <span style="white-space:nowrap"><tt>few</tt></span> <span style="white-space:nowrap"><tt>arguments</tt></span> <span style="white-space:nowrap"><tt>in</tt></span> <span style="white-space:nowrap"><tt>invocation</tt></span> <span style="white-space:nowrap"><tt>of</tt></span> <span style="white-space:nowrap"><tt>macro</tt></span> <span style="white-space:nowrap"><tt>&lt;macro&gt;</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-27405]&nbsp;&nbsp;In rare circumstances, when compiling for T32 state, the compiler could generate incorrect code when explicitly or implicitly adding, subtracting, or comparing to an integer constant and that constant cannot be directly encoded in the immediate field of an <span style="white-space:nowrap"><tt>ADD</tt></span> or <span style="white-space:nowrap"><tt>ADDS</tt></span> instruction. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-26522]&nbsp;&nbsp;When compiling C&#43;&#43; code that stores the address of a member function in a <b><span style="white-space:nowrap"><tt>class</tt></span></b> or <b><span style="white-space:nowrap"><tt>struct</tt></span></b> member, the compiler would place the address of that member function in a read-write data section instead of a read-only data section. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-26133]&nbsp;&nbsp;When compiling a <b><span style="white-space:nowrap"><tt>union</tt></span></b> containing a class type that indirectly includes a <b><span style="white-space:nowrap"><tt>volatile</tt></span></b> class-type field, the compiler would incorrectly report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#294:</tt></span> <span style="white-space:nowrap"><tt>invalid</tt></span> <span style="white-space:nowrap"><tt>union</tt></span> <span style="white-space:nowrap"><tt>member</tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;</span></tt></span> <span style="white-space:nowrap"><tt>&lt;entity&gt;</tt></span> <span style="white-space:nowrap"><tt>has</tt></span> <span style="white-space:nowrap"><tt>a</tt></span> <span style="white-space:nowrap"><tt>disallowed</tt></span> <span style="white-space:nowrap"><tt>member</tt></span> <span style="white-space:nowrap"><tt>function</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-26055]&nbsp;&nbsp;The compiler incorrectly failed to issue any warning when an <span style="white-space:nowrap"><tt>&#95;&#95;attribute&#95;&#95;&#40;&#40;at&#40;address&#41;&#41;&#41;</tt></span> is overwritten by an <span style="white-space:nowrap"><tt>&#95;&#95;attribute&#95;&#95;&#40;&#40;section&#40;"name"&#41;&#41;&#41;</tt></span> or a different <span style="white-space:nowrap"><tt>&#95;&#95;attribute&#95;&#95;&#40;&#40;at&#40;address&#41;&#41;&#41;</tt></span>. This has been fixed. The compiler now reports <span style="white-space:nowrap"><tt>Warning:</tt></span> <span style="white-space:nowrap"><tt>#3730-D:</tt></span> <span style="white-space:nowrap"><tt>section</tt></span> <span style="white-space:nowrap"><tt>name</tt></span> <span style="white-space:nowrap"><tt>conflicts</tt></span> <span style="white-space:nowrap"><tt>with</tt></span> <span style="white-space:nowrap"><tt>previous</tt></span> <span style="white-space:nowrap"><tt>declaration</tt></span> <span style="white-space:nowrap"><tt>.ARM.&#95;&#95;AT&#95;&lt;address&gt;</tt></span>.</p>
    </li>
    
    <li>
    <p>[SDCOMP-26023]&nbsp;&nbsp;In rare circumstances, when compiling code containing NEON intrinsics, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x48c94b:&lt;ver&gt;]</tt></span> or <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x7b3e71:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-26015]&nbsp;&nbsp;When compiling code that contains <span style="white-space:nowrap"><tt>&#95;&#95;attribute&#95;&#95;((bitband))</tt></span> with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=SC300</tt></span>, the compiler would incorrectly report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#1114:</tt></span> <span style="white-space:nowrap"><tt>this</tt></span> <span style="white-space:nowrap"><tt>feature</tt></span> <span style="white-space:nowrap"><tt>not</tt></span> <span style="white-space:nowrap"><tt>supported</tt></span> <span style="white-space:nowrap"><tt>on</tt></span> <span style="white-space:nowrap"><tt>target</tt></span> <span style="white-space:nowrap"><tt>architecture/processor</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25946]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could generate a sequence of code that incorrectly contains a flag&#45;setting variant of an instruction rather than the non&#45;flag&#45;setting variant. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25900]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> or with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span>, the compiler could generate incorrect code for a loop that contains only <b><span style="white-space:nowrap"><tt>if</tt></span></b> statements with bodies that are never executed and are either empty or contain only a <b><span style="white-space:nowrap"><tt>break</tt></span></b> or <b><span style="white-space:nowrap"><tt>continue</tt></span></b> statement. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25894]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O1</span></tt></span> or above, when reading a bitfield of type <b><span style="white-space:nowrap"><tt>long</tt></span></b> <b><span style="white-space:nowrap"><tt>long</tt></span></b> or <b><span style="white-space:nowrap"><tt>unsigned</tt></span></b> <b><span style="white-space:nowrap"><tt>long</tt></span></b> <b><span style="white-space:nowrap"><tt>long</tt></span></b> from a <b><span style="white-space:nowrap"><tt>struct</tt></span></b> that has been declared packed using any of <span style="white-space:nowrap"><tt>&#95;&#95;attribute&#95;&#95;&#40;&#40;packed&#41;&#41;</tt></span>, <span style="white-space:nowrap"><tt>#pragma</tt></span> <span style="white-space:nowrap"><tt>pack&#40;n&#41;</tt></span>, or the <span style="white-space:nowrap"><tt>&#95;&#95;packed</tt></span> qualifier, and the code is not compiled for unaligned accesses, the compiler could generate code that loaded data from memory beyond the end of the <b><span style="white-space:nowrap"><tt>struct</tt></span></b>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25885]&nbsp;&nbsp;In certain circumstances, when compiling code that contains preprocessor macros, Arm Compiler 5.05 (build 41) and 5.05 update 1 (build 106) could take significantly longer than previous releases of Arm Compiler 5. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25845]&nbsp;&nbsp;The compiler would generate incorrect code for a chained <b><span style="white-space:nowrap"><tt>struct</tt></span></b> assignment if the left-hand side of the assignment is a <b><span style="white-space:nowrap"><tt>volatile</tt></span></b> <b><span style="white-space:nowrap"><tt>struct</tt></span></b> and the right-hand side is another assignment expression that does not involve an assignment to or from a <b><span style="white-space:nowrap"><tt>volatile</tt></span></b> <b><span style="white-space:nowrap"><tt>struct</tt></span></b>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25839]&nbsp;&nbsp;When <span style="white-space:nowrap"><tt>&#95;&#95;attribute&#95;&#95;&#40;&#40;const&#41;&#41;</tt></span> or <span style="white-space:nowrap"><tt>&#95;&#95;attribute&#95;&#95;&#40;&#40;noreturn&#41;&#41;</tt></span> is specified for both a <b><span style="white-space:nowrap"><tt>virtual</tt></span></b> method and an overriding method, the compiler would incorrectly report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#1510:</tt></span> <span style="white-space:nowrap"><tt>function</tt></span> <span style="white-space:nowrap"><tt>"&#95;&#95;attribute&#95;&#95;&#40;&#40;&#95;&#95;&lt;entity&gt;&#95;&#95;&#41;&#41;"</tt></span> <span style="white-space:nowrap"><tt>present</tt></span> <span style="white-space:nowrap"><tt>on</tt></span> <span style="white-space:nowrap"><tt>overridden</tt></span> <span style="white-space:nowrap"><tt>virtual</tt></span> <span style="white-space:nowrap"><tt>function</tt></span> <span style="white-space:nowrap"><tt>&lt;entity&gt;</tt></span> <span style="white-space:nowrap"><tt>must</tt></span> <span style="white-space:nowrap"><tt>be</tt></span> <span style="white-space:nowrap"><tt>present</tt></span> <span style="white-space:nowrap"><tt>on</tt></span> <span style="white-space:nowrap"><tt>overridding</tt></span> <span style="white-space:nowrap"><tt>function</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25836]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span>, a combination of optimizations could result in an incorrect transformation, causing the compiler to report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x2732f5:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25830]&nbsp;&nbsp;In certain circumstances, the compiler could generate incorrect code for a copy assignment of a <b><span style="white-space:nowrap"><tt>struct</tt></span></b> that contains both non-volatile and <b><span style="white-space:nowrap"><tt>volatile</tt></span></b> bitfields. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25811]&nbsp;&nbsp;In certain circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;diag</span>&#95;warning=error</tt></span> to downgrade error messages to warning severity, the compiler could incorrectly fail to generate an object file even though it returned a zero exit code. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25767]&nbsp;&nbsp;When compiling a <span style="white-space:nowrap"><tt>main&#40;&#41;</tt></span> function that is declared <span style="white-space:nowrap"><tt>&#95;&#95;declspec&#40;noreturn&#41;</tt></span> <b><span style="white-space:nowrap"><tt>void</tt></span></b>, the compiler would incorrectly report <span style="white-space:nowrap"><tt>Warning:</tt></span> <span style="white-space:nowrap"><tt>#951&#45;D:</tt></span> <span style="white-space:nowrap"><tt>return</tt></span> <span style="white-space:nowrap"><tt>type</tt></span> <span style="white-space:nowrap"><tt>of</tt></span> <span style="white-space:nowrap"><tt>function</tt></span> <span style="white-space:nowrap"><tt>"main"</tt></span> <span style="white-space:nowrap"><tt>must</tt></span> <span style="white-space:nowrap"><tt>be</tt></span> <span style="white-space:nowrap"><tt>"int"</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25761]&nbsp;&nbsp;In certain circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, the compiler could generate incorrect code when integer constant values with the same binary representation are used in two different expressions, and the first of these expressions includes a bitwise Exclusive OR. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25725]&nbsp;&nbsp;In rare circumstances, when compiling for T32 state at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span>, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0xe4ffdb:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25720]&nbsp;&nbsp;When compiling an <span style="white-space:nowrap"><tt>&#95;&#95;ldrex</tt></span> or <span style="white-space:nowrap"><tt>&#95;&#95;strex</tt></span> intrinsic and the pointer argument is not of pointer-to-integer or pointer-to-pointer type, the compiler would incorrectly report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>#31:</tt></span> <span style="white-space:nowrap"><tt>expression</tt></span> <span style="white-space:nowrap"><tt>must</tt></span> <span style="white-space:nowrap"><tt>have</tt></span> <span style="white-space:nowrap"><tt>integral</tt></span> <span style="white-space:nowrap"><tt>type</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25575]&nbsp;&nbsp;In certain circumstances, the compiler could generate incorrect code for accesses to a <b><span style="white-space:nowrap"><tt>volatile</tt></span></b> bitfield member of a <b><span style="white-space:nowrap"><tt>struct</tt></span></b> where the bitfield container is narrower than the bitfield container type but wider than one byte. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25496]&nbsp;&nbsp;In rare circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpp11</span></tt></span> at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span>, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x518125:&lt;ver&gt;]</tt></span>, <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x66a710:&lt;ver&gt;]</tt></span>, or <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0xab8feb:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25485]&nbsp;&nbsp;In certain circumstances, when compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;vectorize</span></tt></span> at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, a loop that copies an array of structures in decreasing address order could be incorrectly transformed by the compiler into a copy by increasing address order. When the source and destination memory areas overlap, this could result in incorrect behavior. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-25465]&nbsp;&nbsp;In certain circumstances, when compiling for T32 state with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span> at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O2</span></tt></span> or above, code containing a comparison with a number that cannot be used as an immediate with the <span style="white-space:nowrap"><tt>ADDS</tt></span> instruction could cause the compiler to report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0xcbb629:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-24118]&nbsp;&nbsp;When compiling with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;debug</span></tt></span> or <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;g</span></tt></span>, the compiler would generate incomplete <span style="white-space:nowrap"><tt>.debug&#95;loc</tt></span> section information for function parameters held in registers. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-23730]&nbsp;&nbsp;When compiling code that accesses an array member of a temporary instance of a non&#45;POD <b><span style="white-space:nowrap"><tt>class</tt></span></b> or <b><span style="white-space:nowrap"><tt>struct</tt></span></b>, the compiler would report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x05ced5:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-23712]&nbsp;&nbsp;In certain circumstances, when compiling code that accesses the <span style="white-space:nowrap"><tt>CPSR</tt></span>, the compiler could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0x674afd:&lt;ver&gt;]</tt></span>, <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0xc43ed8:&lt;ver&gt;]</tt></span>, or <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0xe40a12:&lt;ver&gt;]</tt></span>. This has been fixed. </p>
    </li>
    
    <li>
    <p>[SDCOMP-22697]&nbsp;&nbsp;In rare circumstances, when compiling at <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O3</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;Otime</span></tt></span>, the compiler could fail to apply certain optimizations to loops that include one or more empty statements. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-21864]&nbsp;&nbsp;When compiling code that contains a <span style="white-space:nowrap"><tt>#pragma</tt></span> <span style="white-space:nowrap"><tt>pack&#40;n&#41;</tt></span> followed by a <span style="white-space:nowrap"><tt>#pragma</tt></span> <span style="white-space:nowrap"><tt>pop</tt></span>, with no declarations between them, the compiler would incorrectly ignore the <span style="white-space:nowrap"><tt>#pragma</tt></span> <span style="white-space:nowrap"><tt>pop</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-11575]&nbsp;&nbsp;In rare circumstances, when compiling a C&#43;&#43; constructor for a derived class, and the complete constructors of the object and subobject are not combined, the compiler could generate code that is not fully compliant with the <em>Itanium C&#43;&#43; ABI</em>. When linked with code built using a different C&#43;&#43; compiler, this could result in a run-time error. This has been fixed. This change does not affect compatibility with code generated by earlier versions of Arm Compiler.</p>
    </li>
    

</ul>

<h5>Assembler (armasm)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-25862]&nbsp;&nbsp;When assembling the <span style="white-space:nowrap"><tt>MSR</tt></span> instruction for an Armv7-M processor, the assembler would not recognize the <span style="white-space:nowrap"><tt>&#95;&lt;bits&gt;</tt></span> qualifier for the <span style="white-space:nowrap"><tt>IAPSR</tt></span>, <span style="white-space:nowrap"><tt>EAPSR</tt></span>, and <span style="white-space:nowrap"><tt>XPSR</tt></span> registers. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-23084]&nbsp;&nbsp;In rare circumstances, the assembler could generate incorrect output for the <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;list</span></tt></span> option. This has been fixed.</p>
    </li>
    

</ul>

<h5>Linker (armlink)</h5>
<ul>

    
    <li>
    <p>[SDCOMP-29055]&nbsp;&nbsp;In certain circumstances, when linking using the <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpp</span>&#95;compat</tt></span> option, the linker could report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>L6173E:</tt></span> <span style="white-space:nowrap"><tt>Unmangled</tt></span> <span style="white-space:nowrap"><tt>symbol</tt></span> <span style="white-space:nowrap"><tt>name</tt></span> <span style="white-space:nowrap"><tt>&lt;symbol&gt;</tt></span> <span style="white-space:nowrap"><tt>does</tt></span> <span style="white-space:nowrap"><tt>not</tt></span> <span style="white-space:nowrap"><tt>have</tt></span> <span style="white-space:nowrap"><tt>a</tt></span> <span style="white-space:nowrap"><tt>unique</tt></span> <span style="white-space:nowrap"><tt>mangled</tt></span> <span style="white-space:nowrap"><tt>name</tt></span> as a result of incorrectly processing unnamed namespaces. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28957]&nbsp;&nbsp;In certain circumstances, when resolving an <span style="white-space:nowrap"><tt>Image$$<em>region&#95;name</em>$$Length</tt></span> symbol for an empty execution region, the linker could report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>L6286E:</tt></span> <span style="white-space:nowrap"><tt>ARM</tt></span> <span style="white-space:nowrap"><tt>Linker:</tt></span> <span style="white-space:nowrap"><tt>Execution</tt></span> <span style="white-space:nowrap"><tt>interrupted</tt></span> <span style="white-space:nowrap"><tt>due</tt></span> <span style="white-space:nowrap"><tt>to</tt></span> <span style="white-space:nowrap"><tt>an</tt></span> <span style="white-space:nowrap"><tt>illegal</tt></span> <span style="white-space:nowrap"><tt>storage</tt></span> <span style="white-space:nowrap"><tt>access</tt></span> or a <span style="white-space:nowrap"><tt>Segmentation</tt></span> <span style="white-space:nowrap"><tt>fault</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28370]&nbsp;&nbsp;In rare circumstances, when linking a program using the <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;veneer</span>&#95;inject&#95;type=pool</tt></span> option, the linker could report <span style="white-space:nowrap"><tt>Internal</tt></span> <span style="white-space:nowrap"><tt>fault:</tt></span> <span style="white-space:nowrap"><tt>[0xeb14f5:&lt;ver&gt;]</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-26071]&nbsp;&nbsp;In certain circumstances, when resolving a relocation to a linker-generated <span style="white-space:nowrap"><tt>Load$$</tt></span> symbol, and read-write data in one or more preceding execution regions is compressed, the linker could incorrectly calculate that value of the symbol. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-24767]&nbsp;&nbsp;When generating veneers, a data section that includes a symbol with type <span style="white-space:nowrap"><tt>STT&#95;FUNC</tt></span> would cause the linker to report <span style="white-space:nowrap"><tt>ARM</tt></span> <span style="white-space:nowrap"><tt>Linker:</tt></span> <span style="white-space:nowrap"><tt>Execution</tt></span> <span style="white-space:nowrap"><tt>interrupted</tt></span> <span style="white-space:nowrap"><tt>due</tt></span> <span style="white-space:nowrap"><tt>to</tt></span> <span style="white-space:nowrap"><tt>an</tt></span> <span style="white-space:nowrap"><tt>illegal</tt></span> <span style="white-space:nowrap"><tt>storage</tt></span> <span style="white-space:nowrap"><tt>access</tt></span>. This has been fixed. The linker now reports <span style="white-space:nowrap"><tt>Warning:</tt></span> <span style="white-space:nowrap"><tt>L6171W:</tt></span> <span style="white-space:nowrap"><tt>Code</tt></span> <span style="white-space:nowrap"><tt>symbol</tt></span> <span style="white-space:nowrap"><tt>&lt;symname&gt;</tt></span> <span style="white-space:nowrap"><tt>defined</tt></span> <span style="white-space:nowrap"><tt>in</tt></span> <span style="white-space:nowrap"><tt>non</tt></span> <span style="white-space:nowrap"><tt>executable</tt></span> <span style="white-space:nowrap"><tt>section</tt></span> <span style="white-space:nowrap"><tt>&lt;secname&gt;</tt></span> and <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>L6169E:</tt></span> <span style="white-space:nowrap"><tt>Relocation</tt></span> <span style="white-space:nowrap"><tt>#REL:&lt;rel&#95;number&gt;</tt></span> <span style="white-space:nowrap"><tt>in</tt></span> <span style="white-space:nowrap"><tt>&lt;secname&gt;</tt></span> <span style="white-space:nowrap"><tt>with</tt></span> <span style="white-space:nowrap"><tt>respect</tt></span> <span style="white-space:nowrap"><tt>to</tt></span> <span style="white-space:nowrap"><tt>&lt;symname&gt;.</tt></span> <span style="white-space:nowrap"><tt>Branch</tt></span> <span style="white-space:nowrap"><tt>to</tt></span> <span style="white-space:nowrap"><tt>code</tt></span> <span style="white-space:nowrap"><tt>symbol</tt></span> <span style="white-space:nowrap"><tt>defined</tt></span> <span style="white-space:nowrap"><tt>in</tt></span> <span style="white-space:nowrap"><tt>non</tt></span> <span style="white-space:nowrap"><tt>executable</tt></span> <span style="white-space:nowrap"><tt>section</tt></span> <span style="white-space:nowrap"><tt>&lt;secname&gt;</tt></span>.</p>
    </li>
    
    <li>
    <p>[SDCOMP-17870]&nbsp;&nbsp;When linking a program using <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;list</span>=<em>filename</em></tt></span>, if <span style="white-space:nowrap"><tt><em>filename</em></tt></span> could not be opened for writing the linker would report a <span style="white-space:nowrap"><tt>Segmentation</tt></span> <span style="white-space:nowrap"><tt>fault</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-12939]&nbsp;&nbsp;In certain circumstances, the linker could report <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>L6286E:</tt></span> <span style="white-space:nowrap"><tt>ARM</tt></span> <span style="white-space:nowrap"><tt>Linker:</tt></span> <span style="white-space:nowrap"><tt>Execution</tt></span> <span style="white-space:nowrap"><tt>interrupted</tt></span> <span style="white-space:nowrap"><tt>due</tt></span> <span style="white-space:nowrap"><tt>to</tt></span> <span style="white-space:nowrap"><tt>an</tt></span> <span style="white-space:nowrap"><tt>illegal</tt></span> <span style="white-space:nowrap"><tt>storage</tt></span> <span style="white-space:nowrap"><tt>access</tt></span> instead of <span style="white-space:nowrap"><tt>Error:</tt></span> <span style="white-space:nowrap"><tt>L6286E:</tt></span> <span style="white-space:nowrap"><tt>Relocation</tt></span> <span style="white-space:nowrap"><tt>#&lt;rel&#95;class&gt;:&lt;rel&#95;number&gt;</tt></span> <span style="white-space:nowrap"><tt>in</tt></span> <span style="white-space:nowrap"><tt>&lt;objname&gt;&#40;&lt;secname&gt;&#41;</tt></span> <span style="white-space:nowrap"><tt>with</tt></span> <span style="white-space:nowrap"><tt>respect</tt></span> <span style="white-space:nowrap"><tt>to</tt></span> <span style="white-space:nowrap"><tt>&lt;symname&gt;.</tt></span> <span style="white-space:nowrap"><tt>Value&#40;&lt;val&gt;&#41;</tt></span> <span style="white-space:nowrap"><tt>out</tt></span> <span style="white-space:nowrap"><tt>of</tt></span> <span style="white-space:nowrap"><tt>range&#40;&lt;range&gt;&#41;</tt></span> <span style="white-space:nowrap"><tt>for</tt></span> <span style="white-space:nowrap"><tt>&#40;&lt;rtype&gt;&#41;</tt></span>. This has been fixed.</p>
    </li>
    

</ul>

<h5>Libraries</h5>
<ul>

    
    <li>
    <p>[SDCOMP-28709]&nbsp;&nbsp;The Arm C library function <span style="white-space:nowrap"><tt>&#95;fisatty&#40;&#41;</tt></span> would incorrectly return <span style="white-space:nowrap"><tt>0</tt></span> instead of <span style="white-space:nowrap"><tt>1</tt></span> when <span style="white-space:nowrap"><tt>stdout</tt></span> is attached to a terminal device. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28672]&nbsp;&nbsp;In certain circumstances, the <span style="white-space:nowrap"><tt>std::deque::operator&#43;&#43;&#40;&#41;</tt></span> and <span style="white-space:nowrap"><tt>std::deque::operator&#43;=&#40;&#41;</tt></span> methods implemented in <span style="white-space:nowrap"><tt>deque</tt></span> and <span style="white-space:nowrap"><tt>deque.cc</tt></span> could incorrectly load data from memory beyond the area allocated for the <span style="white-space:nowrap"><tt>deque</tt></span>. This could result in a run&#45;time error. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-28636]&nbsp;&nbsp;The <span style="white-space:nowrap"><tt>std::vector::operator=&#40;&#41;</tt></span> method implemented in <span style="white-space:nowrap"><tt>vector.cc</tt></span> contained an error that would corrupt the internal information of the destination vector when the size of the source vector is smaller than the size of the destination vector. This has been fixed. </p>
    </li>
    
    <li>
    <p>[SDCOMP-25856]&nbsp;&nbsp;The standard C library and microlib implementations of the <span style="white-space:nowrap"><tt>casin&#40;&#41;</tt></span>, <span style="white-space:nowrap"><tt>casinf&#40;&#41;</tt></span>, and <span style="white-space:nowrap"><tt>casinl&#40;&#41;</tt></span> functions would incorrectly return the imaginary part of the result as NaN instead of <span style="white-space:nowrap"><tt>0</tt></span> when computing the complex inverse sine of a real number greater than <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;1.0</span></tt></span> and less than <span style="white-space:nowrap"><tt>&#43;1.0</tt></span>. This has been fixed.</p>
    </li>
    

</ul>

<h5>Other issues</h5>
<ul>

    
    <li>
    <p>[SDCOMP-28980]&nbsp;&nbsp;In certain circumstances, when preprocessing a scatter&#45;file, the link step could require two compiler licenses concurrently. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-26076]&nbsp;&nbsp;In certain circumstances, the tools could unintentionally report licensing error <span style="white-space:nowrap"><tt>9558E:</tt></span> <span style="white-space:nowrap"><tt>System</tt></span> <span style="white-space:nowrap"><tt>clock</tt></span> <span style="white-space:nowrap"><tt>tampering</tt></span> <span style="white-space:nowrap"><tt>detected</tt></span>. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-24626]&nbsp;&nbsp;In rare circumstances, the <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;cpu</span>=list</tt></span> option could incorrectly fail to list the supported processors and architectures. This has been fixed.</p>
    </li>
    
    <li>
    <p>[SDCOMP-17536]&nbsp;&nbsp;In certain circumstances, the tools could fail to find an input file when given a relative path of the form <span style="white-space:nowrap"><tt>./../<em>dir</em>/<em>input&#95;file</em></tt></span> resulting in an <span style="white-space:nowrap"><tt>Error</tt></span>. This has been fixed.</p>
    </li>
    

</ul>




<h4>Known issues in Arm Compiler 5.06</h4>


<ul>

    
    <li>
    <p>[SDCOMP-29910]&nbsp;&nbsp;When compiling for any processor except for Cortex-M processors, Arm Compiler 5.06 (build 20) generates incorrect code for functions that are qualified with the <span style="white-space:nowrap"><tt>&#95;&#95;irq</tt></span> keyword. The generated code preserves only the registers that are required to be preserved by the AAPCS rather than preserving all processor registers. For example:</p>

<pre>extern unsigned int x, y;
__irq void foo(void) { x = y; }
</pre><p>Compiled with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;asm</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O0</span></tt></span> using Arm Compiler 5.05 update 2 (build 169):</p>

<pre>||foo|| PROC
        PUSH     {r0,r1}
        LDR      r0,|L1.28|
        LDR      r0,[r0,#0]  ; y
        LDR      r1,|L1.32|
        STR      r0,[r1,#0]  ; x
        POP      {r0,r1}
        SUBS     pc,lr,#4
        ENDP
</pre><p>Compiled with <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;&#45;asm</span></tt></span> <span style="white-space:nowrap"><tt><span style="white-space:nowrap">&#45;O0</span></tt></span> using Arm Compiler 5.06 (build 20):</p>

<pre>||foo|| PROC
        LDR      r0,|L1.20|
        LDR      r0,[r0,#0]  ; y
        LDR      r1,|L1.24|
        STR      r0,[r1,#0]  ; x
        SUBS     pc,lr,#4
        ENDP
</pre><p>A workaround is to wrap affected interrupt handler functions with assembly language functions that save and restore the additional registers, and remove the <span style="white-space:nowrap"><tt>&#95;&#95;irq</tt></span> keyword from the original functions. For example:</p>

<pre>        AREA     |.irq_workaround|, CODE, READONLY
        EXPORT   |$Sub$$irq_handler|
        IMPORT   |$Super$$irq_handler|
|$Sub$$irq_handler| PROC
        PUSH     {r0-r3,r12,lr}      ; save registers
        BL       |$Super$$irq_handler|
        POP      {r0-r3,r12,lr}      ; restore registers
        SUBS     pc,lr,#4
        ENDP
        END
</pre><p>Arm Compiler 5.06 (build 20) is the only release affected by this issue. All previous releases of the Arm Compiler are not affected. This issue has been fixed in Arm Compiler 5.06 update 1 (build 61) under change identifier SDCOMP&#45;29910.</p>
    </li>
    

</ul>








</body></html>
